Rendering views without React

[alex-dixon]

From the README:

Working with a rules means we know what changes from one state to the next. Given that, we don't need React and its diff algorithm. It also means we don't need subscriptions. If we declare a view in the right hand side of a rule, we can render it when the facts it cares about change.

[levand]

Rather than framing this as "rendering views without React", what would it look like to think of this in terms of "decoupling Precept from React/Reagent"?

I think React can still add value in terms of going from "here is a data structure defining the DOM" to actually updating the DOM. And Precept slots in perfectly to the shouldComponentUpdate part of the React lifecycle.

By thinking of things in terms of "decoupling" rather than "rendering without React", you've made Precept usable with all the ClojureScript React wrappers, not just Reagent, and you've still left the door open for a non-React renderer as well.

[mikegai]

@levand Agreed. We're going to look into decoupling the "props bag maintenance" (data structure for the view) facility from the Reagent ratom so there is neither a Reagent dependency nor an implied React dependency.

[skrat]

I would love to see this being taken a step further, and decouple the rendering entirely. Opening up the possibility for use with non-DOM renderers (eg. Canvas, WebGL, JOGL, PIXI.js, ...). There is an intriguing mention of game-like UIs in the README.

[alex-dixon]

Suggest we keep this issue as "Rendering without React". We believe 1. any React implementation will perform extra work given Precept knows exactly what changes, and that React is not performant enough for some use cases. We should be able to render easily and more efficiently without React's diff algorithm by implementing rules that point update the DOM. In any Precept app, React will be doing unnecessary calculations.

This is one of the project's goals. Precept's rendering should be more performant than React/virtual dom implementations. Combined with being able to express complex logic simply, we might be able to create applications that from a user's perspective are appreciably different (more animations), and from a developer's perspective easier to build, maintain, and reason about.

All that said, we can and should definitely make the framework agnostic with respect to the view layer though per @levand's suggestions. Implementation is being discussed in #75.

[alex-dixon]

@skrat Yes! This is a goal as well that @mikegai has discussed with me. Thank you for adding it to the discussion it definitely needs to be.

[levand]

Awesome: sounds like we're all on the same page about what ought to be done: decouple Precept's change notification from specific view or rendering tools. That should pretty well satisfy all the concerns raised in this thread. People can use any of the React flavors, or abandon React or the browser entirely.

That said, I don't think you should be so quick to dismiss React as a view layer for the browser. It is true that "Precept knows exactly what changes"... in your domain data. But that's a small part of what React does (and actually what it gets wrong, IMO). React's strength is that once you have your updated domain data in hand, you can run a declarative transformation on that to some DOM structure and React will take care of all the bookkeeping of adding and removing DOM nodes and attributes.

Without React, Precept can tell you exactly what domain data has changed but you'd still have to write the piece that actually imperatively updates the DOM based on those new values. That's what React wraps and makes a lot less imperative.