<< > Parker <[email protected]> wrote: > > node.outerHTML is immutable
>> So is a cloned DOM element. The issue is you can't get away from mutability when you're interacting with the real world, and so you have to find a pattern where the immutable and mutable are clearly separated. Sent from my iPhone > On Jul 13, 2015, at 11:40 AM, Joseph Parker <[email protected]> wrote: > > 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. -- 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.
