node.outerHTML is immutable
On Monday, July 13, 2015 at 10:50:35 AM UTC-4, marc fawzi wrote: > Multi-paradigm programming is often required in complex scenarios and one > design pattern does not fit all despite it being of course great! (and > limited) > > > For example, deeply integrating D3 with anything like React has been proven a > terrible idea over and over again since D3 is in a way a DOM differ with > datasets being the state, and the re-inventing D3 transition subsystem using > something like React.tweenState would be an adventure in itself. > > > So then when you arrive at the conclusion that the immutable/reactive pattern > would require you to do far more work that will blow up all your deadline > commitments you may fall back on the language itself but if the language has > no concept of immutability and only way is thru a design pattern that is at > conflict with your current libraries then you find yourself having to > reinvent the wheel that is easiest to reinvent and that would have the most > universal usefulness, which in this case was adding some sort of immutability > to JS. > > > Then these questions came up! What if ClojureScript had to be multi-paradigm > in some complex project then how would you deal with the fact that mutable > things like DOM and atoms can be accessed not only thru the sane design > pattern of React/Flux but also directly. Mutative accidents will happen and > Immutability that is built into the language won't help.. > > > That is, when you think beyond the React/Flux paradigm because you have to do > that sometimes then things start to look shaky. I'm still thinking about it. > > Sent from my iPhone > > On Jul 13, 2015, at 3:11 AM, Gary Verhaegen <[email protected]> wrote: > > > Have you already seen the "Are we there yet?" presentation from Rich Hickey? > I found it quite enlightening on the subject of immutability. > > > With regards to the dom, I think it's more about having the application state > at any point in time being represented by an immutable data structure, and > modeling time as a succession of these structures, with atoms providing the > link between these successive structures, or the identity. If the dom only > contains derived state, then we don't really care that it's mutable, and we > can actually abstract that mutation away like om and the other react wrappers > are doing. > > > As to how to translate all of that to JS, well... I'd look into > omniscient.js, but I've only taken a cursory glance at it. At this point all > I can say about it is that if I had to use JS, that would be the first > library I would evaluate. > > On Sunday, 12 July 2015, Marc Fawzi <[email protected]> wrote: > In JS we don't have native persistent data structures and the ES6 const > keyword only gives us shallow immutability without any of the gains of > persistent data structures. ImmutableJS is nice but existing libraries expect > regular JS maps and arrays. So what i have been thinking is to use ES6 Proxy > with a Frozen reference and that way all writes go to the Proxy object while > all reads come from a diffing operation on Proxy and original object, thus > giving us some form of immutability. For now, however, I've implemented it as > deep freezing the referenced object and using HTML5 structured cloning > algorithm for when a mutable clone is desired. This is admittedly half assed > but it allows me go cleanly isolated all shared mutable state into an atom > like structure in JS. So far so good and it has helped a lot with my D3 app > since D3 charts can be 2000 lines long with a ton of global var use, which > makes them very hard to debug, which is now all eliminated. > > > > Without that i couldnt implement the great ideas I'm learning from > ClojureScript in my JS work. > > > > Sent from my iPhone > > > > > On Jul 12, 2015, at 8:44 AM, Matt Ho <[email protected]> wrote: > > > > > > What problem are you looking to solve here? > > > > > > My take is that immutability is a design pattern rather than something > > enforced by the language constructs. If you want the language constructs > > to enforce immutability, Haskell is an excellent choice. Even Elm (a > > Haskell like language) treats immutability as a design pattern rather than > > a language construct. > > > > > > For me, immutability is a design pattern, much like FP, intended to > > simplify how we reason about apps. I think Om, Reagent, Flux, and Elm are > > all excellent examples of the power of immutable thinking. For comparison, > > the mutable frameworks would be Ember, Angular, and Backbone. > > > > > > M > > > > > > -- > > > 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 [email protected]. > > > To post to this group, send email to [email protected]. > > > 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 [email protected]. > > To post to this group, send email to [email protected]. > > 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 [email protected]. > > To post to this group, send email to [email protected]. > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
