merri/react-tabbordion

Universal, semantic and CSS-only supporting React state managing components for creating Accordions and Tabs

Hello there! 👋

Me + websites I work on = positive effects on all the metrics.

Free tip for great front-end!
If you can solve it without JavaScript, you should solve it without JavaScript.
Progressive enhancement is better than depending on JS.

I love Astro and any other new framework which ditches throwing client-side executed JavaScript at every problem.

The things I do tend to be ahead of the curve, sometimes by years. Which means I'm two things: a continuous learner and autistic.

Currently working on vr.fi, for example contributed a lot to the Junat kartalla service (live train tracker map).

Check my homepage for a blog on web development and lots of other cool stuff.

---

A lot of my stuff here on GitHub has now been outdated by the changing times. For example no more need for react-lazy since you can just do <img loading="lazy" />. What can we learn from this? JavaScript code for the front-end becomes outdated, but HTML and CSS keep on living. Maybe we should work more on just HTML and CSS, and less on JS since it is the short-lived solution until standards make things possible without JS.

react-tabbordion's Issues

Implement checklist

Demo needs a sample of checklist. Content always visible.

Missing tests

Writing these up as these should be tested, but I forgot while writing the new tests from scratch:

• initialPanels
• onChange
• onPanels in both stateful and stateless mode
• panels
• mode

No coverage for tests

Coverage is missing and should be done.

Demo is not working

http://merri.github.io/react-tabbordion/

Clicking on anything here does nothing. Chrome, OSX: latests.

Support React 0.14

Need to update syntax and tests.

Dynamic content issues when animateContent is used

Tabbordion doesn't update height when a panel's content updates and changes height. Should probably add a timeout with a sane default value so that explicit height is removed once animation has happened.

Current workaround is to disable animateContent temporarily to allow height to update.

Accessibility testing / a11y validation

I don't have any devices or software that I could test Tabbordion on. What I've done is based on what I've read on the subject and thus the attributes and logic has been done to the best of my understanding.

This is not enough and external validation is required before v1.0.0 should happen. I don't have much of a clue where this kind of help could be gotten for an open source project.

Documentation style: both position absolute and fixed

Why is there both position absolute and fixed here?

[data-state="tabbordion"] {
    clip: rect(0 0 0 0);
    height: 1px;
    position: absolute;
    position: fixed;
    width: 1px;
    z-index: -1;
}

Implement mobile tabs

Demo needs a sample of mobile tabs. These tabs align in one row and always take all available width. Content animates from left or right depending which was the last active tab. Maybe animate height when in multiple or toggle mode.

This one is surprisingly complex.

Manual testing

Demo needs to be tested and it's CSS polished for true "production quality" status.

Must support

Absolute production quality: animations should feel very good, no glitches when doing things like browser resizes or zooming, and should be fully usable (clicks trigger as expected etc.).

1. Internet Explorer 10 & 11
2. Windows 10
3. iPhone Safari & Chrome
4. iPad Safari & Chrome
5. Androids (which versions, which browsers, which devices?)

Desktop Firefox and Chrome are used in development so they are quite automatically perfect.

"Nice to support"

Animate if possible, make work if possible, make glitch free if possible.

1. Internet Explorer 9
2. Internet Explorer 8
3. Opera Presto 12.17
4. Safari 5.1.7 for Windows

Implement radiolist

Demo needs a sample of radiolist. Content always visible.

Disabled state doesn't work

When I set disabled={true} to TabPanel, this tab is still clickable and it isn't disabled.

Should Tabbordion accept checked (array) and index properties?

Currently it is possible to control state in containing component by manipulating return value of onBeforeChange.

Is this enough?

Fix package.json for Travis

Need to figure out the proper way to indicate React dependency for a component.

Working on a v1 / The Adventures of Misusing Issues

Goals:

1. Both stateless and stateful versions.
2. Use PureComponent: remove workarounds that were made back in the React 0.13 days.
3. Improve props: merge multiple booleans to one prop, use clearer naming convention.
4. Provide separate components for dynamic/animated height of panels.
5. Add helper tools to make creation of customized components easier.
6. Maintain the great parts: WAI ARIA, styling goodness, excellent HTML/DOM structure.

Optional goals: more styles and examples, use merri.net style in demo, modernize demo app (the ES2015+ goodness), server rendered demo, provide helpers (actions/reducers) for managing state via Redux.

In short v1 will be incompatible with the 0.X series and will have performance improvements as a side effect of improving the design.

Render on any parent element via onClick/onChange will block changes

Essentially anything that causes a re-render for component that contains Tabbordion prevents Tabbordion's state to update. This happens because props override internal state. Bug is only in v0.2.3 and not in v0.2.2.

Panel properties can't override properties passed by Tabbordion

At least some of the Panel properties should be possible to override Tabbordion's properties.

React Tabbordion v2

I've put up a CodeSandbox where I'm developing the next version, finally getting rid of many legacy issues that have made this component a bit odd in some regards.

Plans:

• Allow for *any common Tab and Accordion pattern HTML output.
• Support all sensible use cases.
• Abstract just the state management, move all style concerns to user developer.
• Provide legacy compatibility components (if makes sense, not sure about that one yet).

There are still a lot of stuff to do, need to make visual samples of accordion usage as well as allow for multiselection accordions. Also, testing each usage with an actual screen reader to make sure things make sense for end user!