Regarding the Histor圜omponent, it is not a mere presentational component, because there we have the code to handle click events on Elixir functions that were typed by the user in previous commands. ConsoleView, "sidebar.html", assigns ) end end LiveComponent def render (assigns ) do Phoenix. Do not expect to understand all the values passed to individual components just get familiarized with how the parent template markup looks following this approach.ĭefmodule ElixirConsoleWeb. It looks very concise since it is only rendering specific parts and grouping them under very little HTML code. Here is the markup invoked by the ConsoleLive module after introducing components. It is a matter of designing the user interface as a tree of components, each one being responsible for rendering that part and handling events. Note that the thought process is not far from what we do when working with a UI framework in Javascript. We decided to split the user interface into the following parts: It was the perfect solution to break up our massive LiveView module. It offers a mechanism where we can place the event handling and template code that is related to portions of the user interface into more particular files. According to the documentation, these components “are a mechanism to compartmentalize state, markup, and events in LiveView.”. So we arrive at the third option, which is to use live_component/3, a helper that provides us a way to implement parts of our LiveView module that are going to exist in specific Live Component modules. This choice could be appropriate or not depending on your requirements, so it is crucial to consider if the isolation provided by having different processes is necessary. However, it is essential to note that the new LiveView modules will run in separate processes. It allows you to create additional LiveView modules implementing individual parts of your user interface. The second approach is to rely on live_render/3 instead of render/3. But we didn’t feel it was enough because our ConsoleView module still contained a lot of unrelated functions affecting different areas of the interface.
Given that we had all the HTML inlined in the LiveView module, we refactored our code, creating a bunch of template files. The first one is to divide the markup code using different template files. It handled the event triggered when users click on highlighted parts of the commands in the history panel, causing that relevant Elixir documentation to appear in the sidebar.Īccording to the documentation of LiveView, we have three options to consider when deciding to split a LiveView module.Another feature is an autocomplete based on your variables and Elixir-provided functions using the TAB key. This console has the feature to navigate through past commands using the DOWN and UP keys. It handled the event to submit the code, triggering a new render of the UI refreshing the history panel and the sidebar (because variables values could have changed).It rendered the whole UI, including the history panel, the input to enter Elixir code, and the sidebar.Let’s enumerate what was going on in this module, which name was ConsoleView: It was tough to read and reason about this module at that point. However, after some time adding more and more features, the number of events, the amount of template code inlined, and the overall amount of logic made our original Live View module very complicated. At that time, some of the mechanisms related to the separation of components were not clear upfront for us. It was convenient to apply this simplistic approach since we were still learning LiveView. We initially implemented this interface using a unique LiveView component. Another prominent part of this screen displays a sidebar, including the variables created through the session and some additional information. A list of issued commands with its corresponding output uses a significant area of the user interface. It consists of only one screen that provides a way to enter a bit of Elixir code and send it to the server, and then the result of the computation is shown to the user. The application under study is the Elixir Web Console. We will discuss in this article the options we have with Phoenix LiveView to separate responsibilities across different modules, and what we chose in our specific situation. Here is a story about a little application we implemented using Phoenix Live View, how its early implementation looked, and how it evolved when we noticed that the only existing LiveView module was holding too much code.
0 kommentar(er)
