6 ms·

Yup, it works for all $ variables. As for the "_" variables they are meant to have no side effect on the DOM directly and instead only trigger a function calle

Yup, it works for all $ variables. As for the "_" variables they are meant to have no side effect on the DOM directly and instead only trigger a function called $update() automatically, which is where you can deal with all the view stuff. So the only thing you need to remember is to: 1. Declare whaterver "_" or "$" attribute you want to monitor initially on the genotype. 2. Once you have done that, every time you make a change to the underscore or $ variables, they automatically get queued up (via Nucleus) and trigger the $update() function right before the next render frame so they can be drawn all at once in a single frame. There are different ways of doing this, you could directly touch the DOM attributes (without any prefix) or the $ variables and they will update the view from anywhere. But personally my pattern when using Cell to write apps is to NOT directly touch the $ variables everywhere because it can be confusing, but instead keep the underscore variables as sort of a "model", and only touch those. And because updating a _ variable triggers an $update(), I can deal with all the view related stuff (changing the DOM attributes and $ attributes) in one place, inside $update(), which is the "reactive" feature. (But it's really up to you how you do it) You can learn more here https://github.com/intercellular/tutorial#2-update https://github.com/intercellular/tutorial#2-update Hope this helps! p.s. This document may be helpful in understanding the source https://github.com/intercellular/cell/blob/develop/GENESIS.md https://github.com/intercellular/cell/blob/develop/GENESIS.m...

dgreensp 9y ago
Got it. I immediately had a bunch more questions, some of which I tried to answer by playing around with the demo. Is "this" the actual DOM element? (Yes.) Then how is "context inheritance" implemented? The section named "How Cell implements 'context inheritance' does not ever say how it's implemented ;) (Getters and setters are set up by the framework.) It feels like inheriting everything would be a little messy compared to specifying what goes in context. Does changing something in "context" trigger updates in nested components that read that context? Apparently, no. Does assigning to $components always give you brand-new components, or is there any sort of diff/patch as in React? Apparently, always new components and new DOM nodes, so don't recalculate your children; you should probably access them via the DOM API and call methods on them instead. So you don't get "props flowing down" as in React. How are assignments to underscored props coalesced, e.g. using what notion of equality? What should you call props that you don't want to cause an $update? Why is it ok to call methods on other cells from $update, causing further updates, when this is frowned on in React, partly because of timing issues? I sort of wonder if making state changes synchronous is a huge win and solves a lot of issues; a lot of people are wondering if React makes a big mistake there. At the same time, it seems like there would be situations where you update underscored properties on A and B, and A is actually an ancestor of B, so updating A would destroy B. Then you wonder if the framework is going to be smart about the update order, and smart about dealing with defunct components during the update cycle. Edit: That's not even a good example of a timing issue caused by cascading updates. Can't think of a good one off the top of my head. Also edit: I haven't read the code, but it looks really short.

dgreensp 9y ago

Got it. I immediately had a bunch more questions, some of which I tried to answer by playing around with the demo. Is "this" the actual DOM element? (Yes.) Then how is "context inheritance" implemented? The section named "How Cell implements 'context inheritance' does not ever say how it's implemented ;) (Getters and setters are set up by the framework.) It feels like inheriting everything would be a little messy compared to specifying what goes in context. Does changing something in "context" trigger updates in nested components that read that context? Apparently, no. Does assigning to $components always give you brand-new components, or is there any sort of diff/patch as in React? Apparently, always new components and new DOM nodes, so don't recalculate your children; you should probably access them via the DOM API and call methods on them instead. So you don't get "props flowing down" as in React. How are assignments to underscored props coalesced, e.g. using what notion of equality? What should you call props that you don't want to cause an $update? Why is it ok to call methods on other cells from $update, causing further updates, when this is frowned on in React, partly because of timing issues? I sort of wonder if making state changes synchronous is a huge win and solves a lot of issues; a lot of people are wondering if React makes a big mistake there. At the same time, it seems like there would be situations where you update underscored properties on A and B, and A is actually an ancestor of B, so updating A would destroy B. Then you wonder if the framework is going to be smart about the update order, and smart about dealing with defunct components during the update cycle. Edit: That's not even a good example of a timing issue caused by cascading updates. Can't think of a good one off the top of my head. Also edit: I haven't read the code, but it looks really short.