Lustre component: where to draw boundaries?

[gloomy cairn]

Hi,
First of all, thank you for everything. I love Gleam and Lustre. It makes me enjoy web programming more than ever!

I have some design questions about components. I want to create a reusable component that handles a search with autocomplete. The user write a few letters and can choose from a list of rows. I am still learning how to define criteria to evaluate whether it's a good case for a component. This is my first question. Is this set of behaviors a good case? If yes (or no), what criteria do you use to answer? One of the criteria I read in the doc is whether the update function is complex or not. Is there any other criteria?

The other question is whether to let the component handle the fetch effect. I would like to register the component with a function that returns an effect with a message defined by the component. This would take an array of the type List(#(id: String, entry: String)). When the user clicks on the list, the component emits the ID.

As John Ousterhout would say, programming is a problem of where to draw boundaries between modules in a program. I think we learn better by sharing experiences and criteria.

Thanks again!

[dry carbon]

two thoughts:

• this sounds like a good candidate for a component!
• its a good idea to get comfortable implementing things like this without reaching for components first, because i think this is the best way to get a feel for when they’d be a benefit

when thinking about components in lustre i think the best ones are ones that encapsulate complex ui state/behaviour and don’t have much interaction with your business logic or domain stuff, so for example i would create a “search component with autocomplete” and let the app handle the fetching

[timber lance]

Would it make sense for the component to emit an event for the app to then handle and trigger a fetch?

[dry carbon]

yeah!

[gloomy cairn]

Interesting. Can you tell me more about what links the fetch to do the business logic ? It could be hidden in an anonymous function right?

[dry carbon]

data fetching is an application concern not a ui element concern

[gloomy cairn]

Oo ok

[dry carbon]

i like having my application manage that kind of thing and keep components to just encapsulated ui state

not saying this is the right/only way though!

[gloomy cairn]

Interesting. I am gonna try to do both way to get a sense of what I feel confortable with.