General discussion of stateless vs stateful components

[thorsten-de]

Thanks for all the work going on here to build reusable components for live_view using Bulma.

Recently the new implementation of Panel replaced my own rather naive one, but a default slot is missing. Looking into it, the new Panel seems to be a stateful component handling switching tabs etc.

Since now I had the impression that most components in surface_bulma were intentionally stateless and focused on composing the structure needed to make use of Bulma properly.

Concerning Panel, it should work without any tabs at all, as they are optional, like multiple panel-blocks. And for handling tab switching, it has to be considered whether it is just an UI matter and could be done on the client (via apine.js, etc.) or if it requires behavior on the server (data fetching, etc) that should be handled by LiveView.

Imho, surface_bulma should enable both by keeping components as lean and stateless as possible by focusing on composing the presentation needed for Bulma. On top of that, there could be components that make use of these presentations to enable behaviours such as stateful tabs.

Another example would be a Dropdown component. I am working on an autocomplete component based on Bulmas Dropdown, because it is very flexible in displaying the content. In context of an autocomplete function it does make sense to handle state in my component, as there is open/closing the dropdown, a search string, fetching data, selecting an item, switching the trigger component from an input to a more beautiful representation of the item, etc.
But in general, if the Dropdown is just presenting a static bunch of information or links that are followed, a stateless component with properties setting the required classes ("is-active"/"is-hoverable") should be fine. So the component user has the choice how to toggle its state. And when properly thought out, it is easy to extend with stateful features.

Yet another example would be static tables vs interactive ones that enable sorting and such.

Sorry for writing that much, I just thought it would be wise to point out the direction of the library before we start implementing many components this way or the other.

The other point is that I'd probably wait until surface will work well with live_view >= 0.17 before diving into bulma components more deeply. The recent changes decenty messed up my development environment 😄

[justin-m-morgan]

This is a very helpful point for my final work to be done on the pagination component. I had sort of come to this conclusion also, that it should be available as a stateless group of components but also had the idea of providing a configurable container version that did manage state. Any thoughts on that approach?

[Zurga]

I have no real objections with live components for things like modals or the Panel component. At least not until LiveView 0.17 is supported in Surface. A lot of the components are implemented as live components so I don't really believe the argument for 'intentionally stateless' holds up. Furthermore the live components do not use up another process, only more memory. I don't think performance is that big of an issue

Personally, I believe SurfaceBulma should make it easier for the person creating a website to write the code. If there is a performance issue with having a live component somewhere, it can always be made into a non live component by writing the markup in their project.