![]() In general, as long as the function component syntax is utilized, and templates contain no references to any local variables (especially assigns), you can avoid many rendering inefficiencies. It’s the developer’s responsibility to understand how HEEx decides what needs to be evaluated at any given moment, and how stateless component functions take advantage of the stateful nature of parent LiveView processes as part of this decision. LiveView does a lot of heavy lifting to ensure that changes to HEEx templates are efficiently tracked and transmitted to the client. # Please avoid these incantations Conclusion Please, have some empathy for the machine! The following is a large–but not exhaustive–list of examples of template code to avoid unnecessary reevaluations. Any time that a single value in the assigns map changes, every reference to the assigns variable must be completely reevaluated and diffed, even if the rendered output would not change as a result. It should be clear now why referencing assigns is especially dangerous. Any references to a local variable must be reevaluated on every execution of the template, even when its value is ultimately unchanged from previous evaluations. There is no opportunity to decide what to do about the variable, so there is only one logical solution. Any local variable referenced in the template is definitely not tracked in _changed_, because it is not an assign. This warning is not about the size of diffs, but about the frequency of code evaluation within the template.Īs previously discussed, the only mechanism by which HEEx can track changes is to introspect _changed_. ![]() It’s okay to reference variables that are bound inside blocks-such as for list comprehensions, and component slots that use let-but avoid other variable access. This also applies to the assigns variable. Generally speaking, avoid accessing variables inside LiveViews, as code that access variables is always executed on every render. Pitfall: Direct variable accessīefore wrapping up, there is one common pitfall addressed in the LiveView documentation, but is still a very common sight in HEEx templates (emphasis mine): By using the correct syntax for calling function components, we can ensure that changes LiveView tracks will correctly trickle down to the rendered components that care about those changes. Ultimately, when assigns._changed_ is present, the HEEx template takes its data into account during evaluation, so only the smallest changes are returned. Note that it contains the previous person’s data, which will be compared to the current data in the assigns in order to generate the diff. Notably, it only contains information about the person, since that is the only assign that changed in the LiveView. This is a special key LiveView keeps alongside the application’s assigns in order to track what values have changed between successive renders.īy using the proper syntax, _changed_ has been automatically derived from the state of the LiveView and passed down to the function component. %Īh-ha! Here is a first look at the _changed_ field. To render a simple piece of markup, it’s common to leverage basic language constructs-a view helper function that returns a string. This article will explore these examples and a couple others, and demonstrate how to detect and resolve them. The LiveView docs outline a couple of pitfalls in this regard. These inefficiencies are not always immediately apparent, especially when testing the application locally, because the application will appear to display correctly and function as intended. In some circumstances, it may even send diffs when nothing has changed at all! There are some subtle ways to accidentally undermine LiveView’s ability to track changes and, in those cases, LiveView will often fall back to the worst-case scenario: re-rendering a larger portion of HTML than is necessary and sending it across the wire, even if most of it is unchanged. Put another way, LiveView strives to send only what has changed, when it changes. One of the tentpoles of its approach to ensure application responsiveness is to send only very small HTML changes (“diffs”) across a persistent WebSocket connection. Phoenix LiveView empowers Elixir developers to write rich, interactive web applications rendered entirely on the server.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |