History API an app-level concern?

[zeroedin]

I believe there is a need for a discussion about if we make History API for components an app-level concern or if the components themselves control it.

I believe making it an app-level concern would be ok so as long as the API for the component is capable of facilitating the needs of the page.

If it is a component-level concern how should we approach that in a standardized way across all components?

For rh-tabs a super simplified example could be:

<rh-tabs id="history">
  <rh-tab slot="tab" id="tab-1">Tab 1</rh-tab>
  <rh-tab-panel>Content 1</rh-tab-panel>
  <rh-tab slot="tab" id="tab-2">Tab 2</rh-tab>
  <rh-tab-panel>Content 2</rh-tab-panel>
  <rh-tab slot="tab" id="tab-3">Tab 3</rh-tab>
  <rh-tab-panel>Content 3</rh-tab-panel>
</rh-tabs>

window.addEventListener('popstate', event => {
  let tab;
  if (event.state !== null) {
    tab = document.querySelector(event.state.url);
  } else if (window.location.hash !== '') {
    tab = document.querySelector(window.location.hash);
  } else {
    return;
  }
  tab.open();
});

window.addEventListener('load', () => {
  const parentEl = document.querySelector('#history');
  const tabs = parentEl.querySelectorAll('rh-tab');

  tabs.forEach(tab => {
    if (window.location.hash === `#${tab.id}`) {
      tab.open();
    }

    tab.addEventListener('tab-expand', (e) => {
      const state = { url: `#${e.tab.id}` };
      const path = `${window.location.pathname}${state.url}`;
      if (window.location.hash && state.url !== window.location.hash) {
        window.history.pushState(state, document.title, path);
      } else {
        window.history.replaceState(state, document.title, path);
      }
    });
  });
});

[bennypowers]

def. app level. we should remove all this stuff from ui components

[zeroedin]

@brianferry Here is our answer.

[heyMP]

For normal design systems I would say app level. If we're thinking site-system then I would say it should be either a sane default that could be easily opted out of OR a progressive enhancement that can be added.

<rh-tabs history>

OR

<rh-tabs disable-history>

The case for taking on this app level concern in our component is that sites have varying levels of developer resources. By not including history in our components we would just have to be ok with components that have inconsistent behavior across Red Hat.

[bennypowers]

Like, instead we could

// I'm app code
import { HistoryController } from '@rhds/elements/lib/history-controller.js';
const controller = new HistoryController($('rh-tabs'), {... Some config});

[heyMP]

Yeah, probably with history it doesn't make sense. That is a real deal app level concern. Can we take the example of updating the url hash or query params example? Content set is currently giving us that capability and it's an often asked for request.

I agree with you on the history example though, we should leave it out.

[heyMP]

I'm just fairly certain that the pseudo code and examples that we give out will more often never be implemented, unfortunately. So knowing that, it does change how much traditional "app-level" logic I would be willing to include in the RHDS components.

[bennypowers]

Yes I think it's reasonable for us to provide a controller or some other library helper with reasonable defaults for our biggest consumers, as long as it's opt-in and loosely coupled

[bennypowers]

I'm just fairly certain that the pseudo code and examples that we give out will more often never be implemented, unfortunately. So knowing that, it does change how much traditional "app-level" logic I would be willing to include in the RHDS components.

Then we need to cuddle up with Drupal. The solution to those kinds of problems is to excel at pattern manifests, not to compromise on HTML, imo.

[bennypowers]

Summary of consensus from 25-10-2022:

• remove history api from tabs/accordion
• vend a script (initially in @rhds/elements/lib or something) that hooks up history API stuff a la pfe-1, according to the following pseudocode.

  <rh-accordion>
   <script src="/path/to/accordion-history.js"></script>
   ...accordion content here
  </rh-accordion>

• this script uses document.currentScript.closest('rh-accordion')

Why?

• separation of concerns
• progressive enhancement
• web performance
• system maintainability (cognitive load)
• don't block adoption of a web-standards-based development model (import maps, es modules)

While at the same time manifesting the desire to provide maximum support without compromising those above values.

[bennypowers]

cc @markcaron