Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[web] Improve core/Page component and change how Agama layout is hand…
…led (#925) ## The main change As the project evolves, some decisions have been taken in regard to the elements' placement in the UI. Although nothing is set in stone, the truth is that these changes have been steady for several months already. However, the UI internals haven't been updated accordingly to them, keeping a complexity that comes from the early days of Agama when everything was less defined. It is the case of the core/Layout component and its slots, managed by the react-teleporter dependency. They were there because of the need to _influence_ the layout from its children, which fortunately is no longer the case. E.g., it was needed to "teleport" a navigation link from the page or page's section to the sidebar, something that was called "contextual actions". Later, we realized that it was better to have a kind of page menu accessible from the header. What is more, the Sidebar ended up being relegated for holding only Agama stuff, which makes it kind of _static_. Thus, core/Layout and its _teleportable_ slots does not make sense anymore. At this time they just provide a worst DX and a no longer justifiable use of React Portals. Moreover, since core/Page has become a cornerstone while it comes to Agama UI, it looks reasonable to build the layout from there. Doesn't matter if in the future it's needed to manage different page layouts, they can be extracted and _injected_ via core/Page props or using another technique. About performance, it turns out that _rendering everything_ when user navigates from one page to another does not have a so negative impact. Remember that React (the UI library Agama is using) [only changes the DOM nodes if there’s a difference between renders](https://react.dev/learn/render-and-commit#step-3-react-commits-changes-to-the-dom). Furthermore, asking for _re-renders_ on user navigation is not as different from a basic client/server web application: when the user navigates, the server sends back new content and usually there is no performance penalty since browsers know how to do their work efficiently even when for this example they have to fully _updates_ the [DOM](https://dom.spec.whatwg.org/). In any case, _by good luck_ we're constantly trying to keep the DOM size as minimum as possible, see https://web.dev/articles/dom-size-and-interactivity. ## Other things Additionally, some other changes have been done as part of this set of changes, some of them needed to accomplish the main goal described above. Take a look at the commits to know more. ## Notes From #925 (comment): > **A note about using `data-` attributes for styling** > > I started using them for _exceptions_, as [suggested by CUBE](https://cube.fyi/exception.html#exception) methodology which I'd like to follow (WIP). But lately I found myself using them more to make styles easier to understand and, at some level, improve DX. > > I'm aware that CSS _is_ mostly about classes selectors and they are likely to be more performant than data- attributes when used for styling. Though I haven't tested it myself, the potential performance penalty appears to be insignificant. See https://webdev.tips/styling-using-data-attributes#heading-performance-considerations, https://ecss.benfrain.com/appendix1.html, and https://gomakethings.com/how-performant-are-data-attributes-as-selectors/ > > Keeping a balance is the key here. Making use of them when it seems reasonable, and most importantly, trying **not to abuse them**. It's actually **my** goal to **use as few selectors as possible**, regardless of their type. > > Of course, I can be wrong when taking a decision of adding or removing a selector. And that's why I'm adding this note, to let you know what's the main intention behind my _CSS movements_ and to encourage you to join me in the joy of exploring how to make the Agama CSS great and **minimal** at the same time :) > > Also, I've to say that I'm not afraid to make mistakes here. They give me/us the opportunity to learn and improve. Furthermore, CSS **is easy to change and fix**. > > BTW, when looking for evidences about data- selectors performance I found an article talking about [Class-less CSS architecture](https://jacobxperez.github.io/blog/post/css/class-less-architecture/) :innocent: --- Related to https://trello.com/c/h367wPYP (internal link)
- Loading branch information
