Reusable choo components with chooify

First of all my apologies as this is not an issue. I have read a couple of times this discussion about choo state model, and I started writing a browserify transform for choo. chooify.

I’m just starting so is pretty much a work in progress, most of the features described in the repo are not implemented yet, what is already working is a pretty basic management of .choo files. I rewrote the title example with chooify here so you can have a look (that is actually working).

I though in a browserify transform, so the choo repo is not affected, and I want it to show it here to know your thoughts about it. Any help and/or opinion would be appreciated.

[JDvorak]

Reusable components would be a lot easier to manage if models were injected into views explicitly. It would decouple the models from the views, and shift the abstraction toward a world where views are written to expect a particular interface, not a specific model. The need for a coordinating file like a .choo would then be absorbed into the app and routes definitions, ui components would be views expecting specific model interfaces, business logic modules would only be models, and, finally, we all can stop worrying so much about namespaces.

Bonus: this would make re-use of the same view possible with multiple disparate models, start us on the path to standard model interface definitions, and open the door to exploring the potential in higher order models, which I imagine would be like model-level plugins.

[ungoldman]

Sorry to be the naysayer but I think an opposing viewpoint should be added to this thread 😜

I think one of the main benefits of choo is that it doesn’t introduce any new file types (like JSX for example) and doesn’t break JavaScript, The Language™. The biggest appeal to me for choo is that it works without any need for build/compile steps in the electron environment, has a very simple API, and provides a light but robust conceptual framework for dealing with state and dom (basically react/redux: the good parts).

I also don’t see needing to define models and views in separate files as a drawback. In many (most?) cases a view shouldn’t need its own local state, and separating concerns like views and state seems logical to me.

Introducing a new filetype seems like a step in the wrong direction to me. There are already some attempts at creating reusable choo components (like choodown) that could be refined without needing to create another filetype and parse/compile step to go with it.

However that said I am a grumpy old man who hates transforms for dynamic languages 👴 . If it works well for you and solves a problem elegantly then go for it – but I would strongly prefer that a .choo extension not become a core requirement for using choo.

additional comment on the gist here