[LiveComponent demo] Faceted search menu & results demo

[Nayte91]

Hello everyone,

I'm working on a personal Faceted search menu and results page, and I feel like LC is an awesome tool for this job, but needs 1 or 2 tweaks to do it flawlessly.
I also think a faceted menu example in doc/demo can be a superb vitrine of what LC/UX can do 🤩 as it mixes realtime, complex logic (database search), good use of DTOs and a lot more of features delivered elegantly, out of the box, by LiveComponents.

Please be ensured that is not a "do my homework" post (I felt like when writing) but a real, large opportunity for LC to be THE solution for any faceted search, as you can find on e-commerce websites/frameworks, for example (my actual usecase is not for shop btw).

Functional specs

From an index page of a given symfony controller, render a template that renders a FacetMenu & an ArticleResults LCs.

The page accepts some query parameters of various types:

• a "domain" as a string from db,
• a "publicationDate" as date,
• a "name" as regular search string,
• a "status" as string-backed enum,
• a classical "page" as int that reflects articles pagination.

The Facet Menu got several inputs to play with those values accordingly (with a reset button also). When a value is changed, 2 things happens in realtime:

• url is updated with the new parameter's value, allowing user to copy/paste/save this search url,
• ArticleResults is updated according to those parameters.
• I wonder if the FacetMenu should be treated as a Form, as the inputs that re-render the whole act like a form, the url parameters thing is very "action=get"-ish, but I won't call this as a proper form, more a bunch of inputs packed in a LC. That's a genuine web design question! As a 'no' answer could drastically change the process (not using LiveFormTrait..), I will not take it in account in technical specs. But I feel this question must be shared with you, as it can change the best way to design it.

And... That's it. Pretty straightforward, pretty cool, but some challenge are on the (my?) way.

Technical target

I may write some impossible specs below, but at least I'm pretty sure nothing is nonsense here ;) note that below are flawless specs without any workarounds or compromises. As sad as it is, the world is not like that.

• All the url parameters should be received and packed into a Filter DTO, with properties typed accordingly (DateTime, Enum, string, ...), as the MapQueryString feature of Symfony controller does.
• empty values (e.g. index?date=&page=1), null values should be allowed (as long as the type allows it in the Filter)
• only one read of those url params should be done in the code: the ArticleController:index() should not take card of the url params, but the FacetMenu and the ArticleResults do; The first to set inputs accordingly for UX, the second to display results.
• the Filter DTO should be populated from LC with proper types in both LCs,
• for the FacetMenu LC, FilterDTO should be a live property, able to read/write params from/to the URL in real time.
• for the ArticleResults LC, FilterDTO should be readonly, populated from URL in real time.

Challenges

If my specs are OK, I may have found few not-handled-yet challenges for LCs, unless I totally missed a point of the tool's current feature (it may be welcome as a good news).

• [LiveComponent] Make a LC read url parameters at mounting time #2215 --> OK, I actually missed a point 😂
• [LiveComponent] Re-read url query params when re-render? #2233 --> Avoid to not write the parameters thrice and optimize the performances,
• In a regular controller, accept 'empty values' of a typed property as a null one --> Not needed anymore for this topic, but still a nice to have on Symfony side. 'LC produce an url with empty 'date' parameter, and as it is not null, controller tries to transform it as a DateTime and fails, so I handle my date as a string.' --> Entrypoint [HttpKernel] #[MapQueryString] with an empty query string always returns null symfony#50690 (comment)
• [LiveComponent] Multiple URL query params in one LiveProp DTO #2142 --> Improve code readability and reusability, and align behavior from regular SF controller and LCs, that drastically lower the mind burden and learning curve.
• [LiveComponent] Not write url query param when empty/default #2141 --> another way to handle the &date= issue, and clean URL for better UX.

Based on those challenges, issues will be created to address those points, until I totally miss a thing here.