Every state variable is inside the html? What about circular dependencies? What about functions, observables? They can’t be serialized.
Maybe I don't understand it clearly, but if I have some meta info about the items/devices/users, and this meta info size is 5 Mb - will it be pushed to the HTML just to save the state? Are there limits for attributes content length?
Circular Dependencies: Can be serialized after the data is normalized. Think normalizing data to be stored in the database.
Observables: can be serialized as well. See description above how we have observables for data changes on the components and then use querySelectorAll to find the components/listeners.
Yes it involves a different way of thinking about the problem. I think the big point of these articles is that the industry is doing what is easy and as a result it ends up in hot water on TTI. We need to think about what is needed and adjust our development processes accordingly. Yes different is not trivial at first, but it does not have to be hard if you have the right guidance from the framework.
By observables I mean functions. I’ve re-read the post but still can’t find how they can be serialized. Please don't take it as criticism, I’m just trying to get the idea.
Right now I prefer to keep the state inside the rxjs observables, and if Qwik wants to “imprint” every state change into HTML, then all of these functions should be somehow serialized - I have no idea how to do this, but I admit that I don't know every trick existing.
Maybe Qwik is not going to save absolutely everything, maybe it should be the only amount of data, needed to “resurrect” the app from HTML attributes. Or maybe Qwik is not going to save the state on every change.
In the first case, it raises the question, how it will affect the performance if we are going to save-restore the state on every user action (or app internal event).
In the second case, the framework should be extremely smart to determine what state is important and what can be ignored. Or it should be controlled by the programmer.
Those are all excellent questions but explanation would require more text than a response here. Will follow up with more blog posts where we will explore this. The short answer is that the framework keeps caches to make this fast, but caches are done in a way so that loosing them is not an issue for functionality, just performance.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Every state variable is inside the html? What about circular dependencies? What about functions, observables? They can’t be serialized.
Maybe I don't understand it clearly, but if I have some meta info about the items/devices/users, and this meta info size is 5 Mb - will it be pushed to the HTML just to save the state? Are there limits for attributes content length?
querySelectorAllto find the components/listeners.Yes it involves a different way of thinking about the problem. I think the big point of these articles is that the industry is doing what is easy and as a result it ends up in hot water on TTI. We need to think about what is needed and adjust our development processes accordingly. Yes different is not trivial at first, but it does not have to be hard if you have the right guidance from the framework.
By observables I mean functions. I’ve re-read the post but still can’t find how they can be serialized. Please don't take it as criticism, I’m just trying to get the idea.
Right now I prefer to keep the state inside the rxjs observables, and if Qwik wants to “imprint” every state change into HTML, then all of these functions should be somehow serialized - I have no idea how to do this, but I admit that I don't know every trick existing.
Maybe Qwik is not going to save absolutely everything, maybe it should be the only amount of data, needed to “resurrect” the app from HTML attributes. Or maybe Qwik is not going to save the state on every change.
In the first case, it raises the question, how it will affect the performance if we are going to save-restore the state on every user action (or app internal event).
In the second case, the framework should be extremely smart to determine what state is important and what can be ignored. Or it should be controlled by the programmer.
Those are all excellent questions but explanation would require more text than a response here. Will follow up with more blog posts where we will explore this. The short answer is that the framework keeps caches to make this fast, but caches are done in a way so that loosing them is not an issue for functionality, just performance.