Closed bebac closed 8 years ago
In Inesita when we have to render!
we need to generate a whole DOM tree. Then virtual-dom compare it to existing one and update only parts that changed.
In your application you should change store values on every key stroke, so when you render!
things inputs will have a proper value.
Yes, but if a component knows that it is not going to change any state, like the clock example, it could just update its part of the DOM without affecting other "leaf" components. They can just return their "cached" virtual nodes. I think this could be an option and it wouldn't change the default behavior of Inesita any way.
I have put together a small demo: https://github.com/bebac/inesita-partial-render-demo
It can be done without Inesita changes: https://github.com/fazibear/inesita-partial-render-demo
Sure, that works for the example
Hi
This is not really a bug report, but I ran into a problem which I have been struggling a bit to solve. I have an Inesita application which receives quite frequent events through a web socket. I also have a view with some input fields. Now you probably already guessed my problem :-). Anyways, some of the websocket events calls render! which then resets the input fields back to the stored value. As an example let's say we combine the clock example with the Input example.
Now if the user is typing something into the input field and Clock component calls render!, it is reset.
Is there some trick to avoid this?
I created a fork https://github.com/bebac/inesita, where I hacked in support to (re)render a component only. That is a componet can call
render!(self)
. For that to work one has to mark components, to not render, as a leaf nodes (leaf nodes being components that do not have sub-components).I guess, I am proposing some finer grained control over what is rendered or maybe there is an obvious solution to the input-field-getting-reset problem that I just don't see.