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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

live: Implement config propagation utils #170

Open
s0 opened this issue Aug 27, 2023 · 0 comments
Open

live: Implement config propagation utils #170

s0 opened this issue Aug 27, 2023 · 0 comments

Comments

@s0
Copy link
Member

s0 commented Aug 27, 2023

One of the biggest parts of work to componentise existing code, or to create new components, is to link together all the config updating and propagation up & down, and respond to config change events, and pass that down to each of the individual child components.

This process could be simplified if we introduced a modular way of propagating configurations, and linking sub-configurations. We could also simplify the handling of more specific types at type boundaries (such as plugin config / input config) by doing the type checking in a single place, and just linking using unknown to reduce the need for type coercion.

It would need to:

  • accept applyConfig and

  • allow for adding children, example:

    const childConfig = c.addChild(
      // Get current value
      current => current.children[id],
      // Update current value
      (current, update) => ({
        ...current,
        children: {
          ...current.children,
          [id]: update(current.children[id])
        }),
      // Optional: delete current child (required for `.delete()`
      (current) => {
        const children = {...current.children};
        delete children[id];
        return { ...current, children};
      }
    );
  • allow for "updating" config with an updater .update(current => { /* */ }).

  • allow for "deleting" the config .delete().

  • automatically skip applying config when nothing has changed (so we don't need this logic in each component).

  • Have event listeners for delete and changed.

Then usage would just be to initialize sub-components with one of these in the constructor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant