So I was supposed to have done this one the weekend but my 20 month old baby girl objected.
I've finally managed to clean up the project and comments so that it is understandable to others. It's a learning project that has taught me: 1) the importance of Real FP (as opposed to sprinkling FP patterns through out, and missing our on core essential concepts) 2) the risks of over thinking the problem 3) the risks of under thinking the problem 4) stepping out of your own [frame]work every now and then and getting some fresh air (in this case ClojureScript + Reagent) Here is my in-retrospect-embarrassing attempt at state driven polyglot rendering Github: https://github.com/idibidiart/stateful Youtube: << WATCH ME FIRST >> https://www.youtube.com/watch?v=UacbvV4GpYk What the video demonstrates: Single Page App (SPA) framework based that supports stateful UI components with independenlty developed HTML/CSS/JS, D3/SVG, Canvas or WebGL widgets (the code has a D3 widget example used in a stateful component) It stores all UI state as well as all derived data (e.g. data that has been transformed and made consuable by some widget) which can be accessed by value (immutable) or by reference (mutable) It remembers the entire state of each page, thus allowing for things such as state transfer (between users at the component or page scope) as well as recording and replay of user interaction. Parallel fetching data and storing in state model prior to rendering the entire page all at once upon page transition, so new and old pages appear instantly. Usually, SPAs transition to the page then render it in piecemeal fashion after the page has already been transitioned to, leading to an ugly experience. The key is that everything appears instantly in both forward and back directions (new pages and previous pages are rendered from optimized state object data structure that has already been populated with data) What the video doesn't show but is already implemented and can be seen in the code: You may choose HTML, SVG, Canvas, WebGL or any technology available from the Javascript environment with Stateful.JS and get the benefits of stateful rendering for free. In other words, using Stateful.JS you only work with the app's state via an optimized state object, and not directly embedding state into the DOM (HTML or SVG), or individual data structures in case of Canvas and WebGL. The UI components, which can include independently developed widgets (in any technology, e.g. SVG or WebGL) are rendered onto the DOM from the state object (the root HTML elements in case of Canvas, SVG and WebGL), so the main architectural advantage here is not only the separation of state from the DOM but also the separation of state from the rendering technology. This is achieved at the developer level by specifying Rendering Scheme that may use whatever technology to draw on the screen and handle UI events while having the state of the app in one data structure outside of the view and independent of the rendering technology. Stateful.JS was designed for real world scenarios where UI components built in a completely different technology, not just different component model, may be utilized, with the benefit of retaining state outside of the view (the view will still have its own state in the HTML or SVG DOM, Canvas, or WebGL, but it flows in one direction from the state object to the DOM and widgets attached to the view's DOM tree. Stateful.JS does not have "data models" like in Backbone, but an optimized data structure for storing state and derived data. The raw data received from the server would be stored in a caching layer like IndexedDB with user developed NoSQL query API [I have something in the works, too]) StatefulJS llows Designers to work with HTML or SVG DOM tree prototypes which are then expanded into the actual rendered structures. The renderer is blazing fast and does not use string concatenation. Use pre-existing framework-independent HTML/SVG/Canvas/WebGL widgets in Stateful.JS components: See the D3-powered chartWidget.js and the ListView Stateful.JS component in components.js for an example of using pre-existing, framework-indepedent D3 widget inside of Stateful.JS components. Similarly, framework-independent HTML, Canvas and WebGL components (developed with any library) maybe used inside of Stateful.JS components. What is next: Implementing the current persistent chart widget example with Canvas and WebGL (click more in search results to see current example using a D3 widget) On Friday, 23 January 2015 11:27:50 UTC-8, marc fawzi wrote: > actually I realize now why the virtual dom is so cool in an FP paradigm like > ClojureScript: it simply orients you toward data and UI state and you never > have to even map back to the DOM ... > > > having said that, I bet that I can find a similar way to achieve the same > purpose without the magic of virtual dom ... but it won't be as pleasant ... > we'll see .. will post my code over the weekend > > > On Thu, Jan 22, 2015 at 6:26 AM, Marc Fawzi <marc.fa...@gmail.com> wrote: > > sure, it's work in progress, and for now showing use of D3 widget written > independently (using D3's own reusable component pattern) and simply hooking > into the state layer (which holds the data for the chart as well as the > pan/zoom of the brush on the chart) which it is then rendered from (by the D3 > widget itself)... that 'bridging' is specified as a custom rendering scheme > which could also be done for any independent/3rd party canvas or webgl > widget... the changes to the d3 chart are two lines to store state in the > state layer I provide .. same would be for any webgl or canvas widget, i.e. > minimal code to hook into the state layer ... > > > I'm looking at the ClojureScript atom and the Reagent ratom version to learn > more > > > I'll post the github link by Monday, needs some comments and cleaning up > > > > > > > > > On Wed, Jan 21, 2015 at 8:16 PM, Mike Haney <txmikes...@gmail.com> wrote: > Well, Reagent and Om will trigger the renders for you as well, and even batch > renders. > > > > What sounds novel about your approach is doing the same thing for canvas and > webgl. Are you saying you have a library that does this for the dom, canvas, > and webgl all at once? That I would be interested in seeing. > > > > > > -- > > Note that posts from new members are moderated - please be patient with your > first post. > > --- > > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescript+unsubscr...@googlegroups.com. > > To post to this group, send email to clojurescript@googlegroups.com. > > Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
