The following problem occurs all the time:

const props = {a: 1}
const defaultProps = {}
const props2 = {...defaultProps, ...props} // => {}

When a function return value / prop is null / empty / undefined things can go out of control.
Make sure there are sane defaults and return types which work in all conditions.

So it's not outlined in the W3C Validator

Perhaps they should be integrated with tests.

• It was made to work with model based testing using Cypress.
• It's very very complicated. Lots of concepts to learn.

This simple case:

isHomePage
  ? setMenuState("HOMEPAGE")
  : isPortrait
  ? setMenuState("PORTRAIT")
  : setMenuState("LANDSCAPE");

in XState would require transient states and guards.

See https://github.com/osequi/test-cypress for details

When adding a new font first the TFontNames has to be updated in Fonts, then modifying the theme. It's too much work.

For example:

const maxWidth = useMaxWidth({ maxWidth: 25 }); => const maxWidth = useMaxWidth(25);

It seems this is not working: export type TTypographicScaleSettings = TLinearScaleSettings | TModularScaleSettings | {};
Later you can't access settings.base or settings.ratio

But this is working: export type TTypographicScaleSettings = TLinearScaleSettings & TModularScaleSettings;
settings.base or settings.ratio are accessible.

• More and more problems: see xstate/fast refresh bug, which is a bug even without xstate. statelyai/xstate#1702
• Very rude staff: vercel/next.js#17478 (comment)
• Very autocratic way of handling stuff: vercel/next.js#19155
• Not caring at all: vercel/next.js#13268

The main idea behind theming is to enforce rules thus keep things uniform.

An example:

/**
 * Defines the default link style.
 */
const defaultLink: TLink = {
  preset: "default",
  colors: {
    default: "default",
    active: "inverted",
    visited: "default",
  },
  settings: {
    default: {
      textDecoration: "underline",
    },
    active: {
      textDecoration: "line-through",
    },
    visited: {
      textDecorationColor: "red",
    },
  },
};

A link can be freely styled through settings when those settings are not present in the theme. When a setting is present in the theme (colors) it should be moved out from settings. This would like to enforce the usage of the same colors across the design system.

For example textDecorationColor: "red" will break the color system.

This strictness might not scale well.

For example, what if we want bold links? Setting fontWeight: 'bold' on deafult would again break the font system. Instead we should use the 'Nimbus Sans Bold' font through a hook. That would result in adding a new section fonts to the already existing colors and settings. And this might not scale freely.

Perhaps an error-prone, totally uniform design system doesn't scales so well.

useScale(0) was returning null because instead of isNil(points) we had (!points)

The following code chunks repeats. It can be refactored into a utility hook.

let queries = {};

  responsiveColumns &&
    responsiveColumns.map((item, index) => {
      const breakpoint = breakpoints[index];
      if (!breakpoint || !breakpoint.name) return null;

      const query = useBreakpoint(breakpoint.name);
      if (!query) return null;

      queries[`${query}`] = {
        gridTemplateColumns: `repeat(${item}, 1fr)`,
      };
    });

  return queries;

useTheme, useMediaQuery from /hooks are real React hooks, or rely on real React hooks. However the whole /hooks folder test environment is set to node.

For now these 'hooks' have their tests commented out, but real testing should be added.