4 ms·

Thank you, I think you pretty much nailed it! This architecture may not be very obvious to many people at this point but I believe it can enable a lot of inter

Thank you, I think you pretty much nailed it! This architecture may not be very obvious to many people at this point but I believe it can enable a lot of interesting use cases (as well as being able to deal with even traditional app structures in more efficient and cleaner ways) One example is my own use case, where I'm working on a web version of Jasonette https://www.jasonette.com https://www.jasonette.com I couldn't find any existing framework that can achieve what I was trying to without becoming very complex. Thank you for the encouragement, you made my day :D

dgreensp 9y ago
Sure thing. :) One thing I'm not completely clear on is the reactivity model. It seems like setting $components (for example) triggers a setter that updates the DOM? What about other DOM properties? What about underscore properties? Is there a dependency graph under the hood, and can you set up a property to depend on a calculation based on another property? Or is all data propagation explicit/imperative/"push"?
- gliechtenstein 9y ago
  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

Sure thing. :) One thing I'm not completely clear on is the reactivity model. It seems like setting $components (for example) triggers a setter that updates the DOM? What about other DOM properties? What about underscore properties? Is there a dependency graph under the hood, and can you set up a property to depend on a calculation based on another property? Or is all data propagation explicit/imperative/"push"?

gliechtenstein 9y ago
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.