SearchBar broken with controlled input

[lsagetlethias]

• Search button disapear when focus:
  Straight from storybook:

  • Before focus
    

  • During focus
    

• "big" state is not aligned

  • code
    
  • screenshot
    

Why introducing those kind of breaking changes and diverge from Input component?

Node : 20.6.0
React DSFR : 0.75.5
Chrome : 116.0

[garronej]

Hello @lsagetlethias,

Thank you for reporting the issue with the search bar in controlled mode. The issue has been fixed.

I understand that changes to the button's behavior can be frustrating, especially if you don't see them as adding value to your project.

However, I believe the search bar is a crucial element for any government website. To this end, I have updated the component to accommodate the implementation of a modern search bar, complete with real-time autocomplete and suggestions.

The search bar, as originally designed by the DSFR team, follows the Web 1.0 paradigm. It expects the user to type a query and then click the search button; the server then responds with a new page displaying the results. If you wish to implement a more traditional search bar, you can use the onButtonClick callback like so:

<SearchBar onButtonClick={text => /* handle the text query, perhaps send a POST request */ } />

What we aim for—and what React enables us to do—is provide real-time results as the user types. In such cases, there's little reason to have a search button that serves no function since results are displayed in real-time.

Here is an example of a real-time search bar using MUI's Autocomplete:

Screen.Recording.2023-09-12.at.07.07.08.mov

I plan to add this component to the library, although I haven't had the chance to do so yet.

That said, if the disappearance of the button is a blocker for you, I can make it so that the button will only disappear if the realTime: true prop is set. By default, the button will remain. Would this solution work for you?

[lsagetlethias]

Thank you for your quick response.

There is no frustration here, only concern about the future and the continued strict implementation of the DSFR.

My worry stems from the potential divergence from the original specifications, even if they do not fulfill all the prerequisites for a clean website. I am referring to changes that are not only breaking from a code/technical standpoint but also moving away from strict DSFR compliance.
I also doubt that a lack of consistency between similar components could be beneficial in terms of usability and maintenance.

I understand the need to enable key features and ensure compatibility with MUI and other frameworks, and even with other web standards. However, I believe that such changes could be confined to specific components or, better yet, be made pluginized.

Bear with me on this; the library is outstanding! It greatly facilitates the use of DSFR in React projects. Now that it is widely used, some stability would be greatly appreciated. (Changelog, v1, upgrade guide, etc)

In the meantime, sure we go on the realTime: true route, it will help keeping the display as intended by DSFR. Thank you a lot for that.

[garronej]

My worry stems from the potential divergence from the original specifications, even if they do not fulfill all the prerequisites for a clean website.

To clarify, this is the only instance where there is a deviation from the original specifications. I made this change intentionally after receiving acknowledgment from the team. They had not yet provided guidelines for real-time input.
As I previously mentioned, this issue was a bottleneck for the implementation of the search bar:

https://github.com/codegouvfr/react-dsfr/assets/6702424/4d8f7c92-3036-4cc8-a05e-79e0e6aed498

I also doubt that a lack of consistency between similar components could be beneficial in terms of usability and maintenance.

I make a concerted effort to ensure consistency in the API; a significant amount of work goes into this.

Bear with me on this; the library is outstanding! It greatly facilitates the use of DSFR in React projects.

Thank you for the kind words.

some stability would be greatly appreciated

Achieving perfection the first time around is challenging. I'm aware of the stability issues at this stage but am optimistic things will improve. Despite not keeping a pre-v1 changelog nor an upgrade guides, I do keep the documentation and the starter project up-to-date, which is quite time-consuming.
I'm open to submitting PRs to any project facing difficulties when upgrading to a newer version of react-dsfr.

In the meantime, sure we go on the realTime: true route, it will help keeping the display as intended by DSFR. Thank you a lot for that.

Upon further review, to prevent the search button from disappearing, it's sufficient to provide either onSearchButtonClick (<Header />) or onButtonClick (<SearchBar />) alongside renderSearchInput.
In other words, if there's no action tied to the button, it makes sense for it to disappear.

Let me know if this works for you.