Some little doubt about the cell

[monkingxue]

First of all, thanks all contributors of cell! I like this framework! I think it's succinct and elegant, likes a cute kitten~ But I still have some questions about this project：

• I have tried some demos about cell, I find if I want to change the data of DOM, I just assigned value to $text or something else. It's easy to understand, but if I change the value many times, can cell merge these changes to one just like React or vue?
• When I used jQuery a few years ago, I selected DOM and change the value; When I used React one year ago, someone tell me that don't operate DOM directly and just change the state. I find the code in cell is mixed these two thought, how contributors think about?
• Because I am a React lover, I like JSX and I think it may be more intuitional than a JS-Object style component, so is supporting JSX possible in the future?

Last but not least, thanks all contributors again!

[ghost]

I'm sure they'll appreciate it! While I'm not a contributor I think I can answer your question in part.

First off cell is designed to work directly with the DOM. Cell's job is to give you a way to manage state on DOM elements with the ability to redraw child elements with a minimal diff'ing when changing the _ and $ properties of a cell you request a new animation frame so you draw everything at the same time. But the key take away here is that Cell is a DOM creation pattern. It's JSON api lets you declaratively create DOM elements in a consistent way. So if I understand you're first question the answer is yes. Changing stateful values on an element can allow for changes to be applied together in a single patch.

To your second point. Yes, React uses a virtual DOM to track target DOM state from prior DOM state. This is a huge win in many regards (especially from the perspective of functional programming) but it has it's drawbacks which are covered some in the README.md. Cell gives you a some what a similar interface with $components where you can set the attribute with your JSON cell schemas and you'll redraw the DOM but there is no virtual DOM.

As for JSX, I personally fell it detracts from your ability to do more abstract function composition with the JSON structures. Regardless of my opinion, someone has been playing around with the idea referenced in #115 https://github.com/devsnek/to_cell

[monkingxue]

@kingoftheknoll thank you soooooooooo much about your response!

[gliechtenstein]

@monkingxue thanks! I'm glad cell feels like a cute kitten haha, and thanks @kingoftheknoll for the thoughtful answer. I'll just add a couple more points since most have been addressed by @kingoftheknoll .

Regarding "don't change the DOM directly", yes that is true and cell does not directly change the DOM directly. Internally each node maintains a data structure called Genotype, which is where all the data is actually stored. And there's another module called Nucleus, which functions as a proxy whenever you try to access the node.

So for example when you do something like this:

{
  $cell: true,
  $init: function(){
    this._counter++;
  }
}

You are not directly updating the _counter variable on the node. The trick is the Nucleus module abstracts out the setter and getter so that while it looks like you're directly touching the DOM, it always goes through the proxy and never touches the DOM directly.

And Nucleus also queues up all these Genotype variable updates and batch updates them on every tick, which gets rid of all the reflow problems you mentioned.

And I agree with @kingoftheknoll that JSX limits the power of what you can do with Cell. By using pure Javascript there's no distinction between model, view, and controller anymore and you can do some seriously clever stuff.

But then again, at the end of the day, the real power of Cell is that it's natively pluggable to anywhere so you can use the to_cell module by @devsnek and you can even use handlebars https://play.celljs.org/items/1mQfq1/edit There are probably other cool ways of doing this that I'm not aware of.