Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Considerations for progressive enhancement #1622

Open
2 tasks
theetrain opened this issue Jan 10, 2023 · 4 comments
Open
2 tasks

Considerations for progressive enhancement #1622

theetrain opened this issue Jan 10, 2023 · 4 comments
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Milestone

Comments

@theetrain
Copy link
Collaborator

theetrain commented Jan 10, 2023

馃毀 Status: Draft 馃毀

The following items are needed in order to enable progressive enhancement capabilities for prerendered or server-rendered components:

General: documentation

Add a special section for progressive enhancement, and provide badges for every component that contains explicit support for it. We may also want a checklist system for all components; that way it's clear which components does or does not support certain functionality.

General: Form actions and href

See #1599

  • components with an inner button should provide a formAttributes prop that is of type { formAction: fn } | HTMLAttributes<form>

    Example:

    <FluidForm formAttributes={{ action: "?/addItem", formAction: enhance }} />

    Underlying component has:

     <script>
       export let formAttributes: HTMLAttributes<form>
       $: ({ formAction, ...formAttrs } = formAttributes)
     </script>
     <form {...formAttrs} use:formAction />
  • components with inner buttons that can change data or state may receive an href prop, allowing users to choose a new page or the same page with searchParams, impacting the displayed information

UIShell

WIP

  • use media queries for responsive styles

Accordion

WIP

Breakpoint

  • discourage use for progressive enhancement
  • Consider providing utility classes or components for responsive show/hide logic

<Button>

  • <Button> can leverage the native formaction attribute to set its individual formaction path
  • SvelteKit's use:enhance only applies to <form> elements (see demo for enhanced button formaction); so we would have to either wrap <Button> or advise users to provide their own <form> since <Button> is a primitive single-element component
  • ButtonSet can have its vertical or horizontal style set with CSS media queries

Modal

WIP

DataTable

WIP

Combobox

WIP

Dropdown

WIP

Tabs

WIP

Toggle

WIP

Tooltip, Tooltip Icon, Tooltip Definition

WIP

Theme

WIP

UIShell

  • Menu items currently toggle on click. It may be possible to leverage :has and :active in order to keep sub-menus open after clicking on them without JS. Otherwise, we'll consider these 'enhanced with JS' and provide href props to the top-most links, and encourage users to provide index pages for top-level links

Tasks

  1. documentation
  2. breaking changes
@gohde
Copy link

gohde commented Mar 22, 2023

In terms of using sveltekit's form actions, would it be possible to add an option to the modal to have the primary button be of type submit? or have the buttons as a slot in order to pass in custom buttons. That way we can wrap the modal in a native form and have the whole thing work as intended by sveltekit?

@theetrain
Copy link
Collaborator Author

@gohde absolutely. Though the actual implementation is yet-decided, we'll try to find a way to make the modal's buttons submit as a form. The tricky thing with some modals is they don't open easily without JS, so part of the exploration is to find a pattern that would allow the page to fully refresh without JS and display an opened modal that has a submittable form.

@gohde
Copy link

gohde commented Mar 22, 2023

I had a similar issue with Tabs and ended up solving it using route params. As you tabbed around it would update the url. It worked fine and I don't see why that couldn't work with this also. [[modal]] or with nested or several modals using [...modals]?

@theetrain
Copy link
Collaborator Author

I'm sure it's achievable, I guess I was needlessly concerned with a potential refactor for Modal, but we'll cross that bridge in time.

Aspirations include:

  • Tabs will support an href prop, and <button formaction="" />

  • Modals can be opened with CSS when the open prop is true in the case of a page reload; whether navigating to a new url or via query params such as /page?confirm=true that yields an SSR-opened modal. Modal buttons can support pass-through props such as:

    <Modal primaryButton={{ form: "confirm-form", href }}>
      <form id="confirm-form">
      </form>
    </Modal>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants