Composability Patterns for Hologram - Looking for Your Ideas

[bartblast]

@nikfp

For mixins as you described, I can see the dx being comfortable in simple cases, but I can also see that turning into a headache as things gain any complexity. Thinking about testing and debugging for example, you would have to grok the component and everything that has been injected into it to work on or diagnose anything.

That’s definitely a valid concern with mixins. Though macros could inject introspection utilities to help with that. Just one of the options to consider.

@nikfp

Namespacing could be interesting. I was thinking in my example that the keys would relate to the root component and the store together, and the machinery behind isolating all of that would be largely abstracted. The usage would be explicit though. It sounds like you are thinking that the namespacing would be more explicit and the plumbing would be abstracted and hooked up during compile time. Which is fine, and that’s what some JS frameworks already do, so I don’t think the mental overhead would be hard to grasp for users.

I’m considering two main approaches (with different variants) for namespacing:

1. using the module as a namespace key, like def action({Togglable, :do_sth}, ...) where action names, state, etc. get namespaced automatically.
2. explicit prefixed keys like def action(:togglable_do_sth, ...).

Still an open question how to integrate this cleanly and whether full automation is feasible.