Refactor Candy View to Decouple from Candy Core

[terraboops]

A follow up to the comments in #404 regarding the architecture of Candy View.

The current implementation of Candy's interface has coupling issues which make it difficult to customise and extend. If Candy View were decoupled from Candy Core, it would make this much simpler. The CSS is also similarly coupled and lacking a cohesive architecture. These issues have essentially grown organically over time as the project aged and the number of contributors grew, as it does with most projects.

This is an issue to discuss / design and possibly implement a new, decoupled view-layer.

IMHO, this refactoring should be heavily influenced by Web Components, specifically we should aim to hit as many points on this list as is reasonable:
https://github.com/webcomponents/gold-standard/wiki

Currently, Candy relies on jQuery and Mustache to roll it's own view-binding system. It has been suggested that this mechanism be replaced, possibly with React. Using React would also make it very simple to implement a Web Component-style architecture.

Some questions I have, feel free to add more:

• What kinds of use cases are we trying to support?
• What parts (specifically) of the current Candy implementation do not support these use cases?
• How far do we want to take the de-coupling / isolation of Candy into a component? How many points of the "Gold Standard" linked above do we support?
• Should we specifically support theming or just try to make the styles more cohesive?
• Should there be a definite plugin architecture with specific extension points or just expose everything for Monkey Patching?
• What framework should be used? (React?)

[korobochkin]

:)

[terraboops]

Cool 👍

Looks a lot like Slack / Kaiwa

This interface would not fit my use case at all -- not sure about others.

I had hoped the discussion in this ticket would be agnostic to a design idea and instead be strictly about decoupling the View code from Candy Core. Doing that would make it easier to skin Candy in various ways, this design could be one of those skins / themes.

[benlangfeld]

Thanks for contributing those ideas, @korobochkin! I'd love to hear your thoughts on #412 too.

@tylermauthe I agree that we need to make it easier to skin this. That'll be a key consideration taken in any changes going forward.

[terraboops]

@benlangfeld That's awesome, any thoughts on how we approach that? So far, this issue isn't getting any traction and I'm inclined to close it soon.

[benlangfeld]

@tylermauthe I wouldn't worry about closing it; it's not been open long and we're all very busy. I will note though that Mojo Lingo, who sponsor my maintainership of Candy, are hiring a frontend developer who will be working on related applications and likely contributing to Candy. Additionally, I'm witholding my thoughts on the questions you pose in this issue pending a fuller response to #412 and robust positioning of Candy as a project to properly inform its implementation.

[terraboops]

@benlangfeld Fair enough, I will attempt to acquire some patience!

[lkraav]

I've gotten strong signals from a couple of trustworthy sources (extensive experience with all current mainstream JS frameworks), that going React is indeed the current optimal choice. The "HTML in your JS" for React makes for more sensible things than "JS in your HTML" of Angular, Ember etc.

Related reading https://medium.com/@housecor/react-s-jsx-the-other-side-of-the-coin-2ace7ab62b98