Considerations for progressive enhancement

[theetrain]

🚧 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

### Related Tasks
- [ ] #310 
- [ ] https://github.com/carbon-design-system/carbon-components-svelte/issues/1006
- [ ] https://github.com/carbon-design-system/carbon-components-svelte/issues/1006

[gohde]

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]

@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]

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]

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>