refactor: old array conversion

[0o001]

https://stackoverflow.com/a/54793076
https://www.measurethat.net/Benchmarks/ShowResult/464484

[AykutSarac]

@muratcorlu Are we sure that we want to support the search input type that way? We haven't discussed the UI/UX decisions of this component. I'd say avoid the effort before the discussion.

[muratcorlu]

@AykutSarac Good question. I'm not sure. What kind of consequences do you predict? Do you mean considering to use a relevant icon while we use search input?

[0o001]

There are two CSS tags we can use for "search" One is for the search input, and the other is for the search results. Additionally, if this matter is important, you might consider evaluating this situation for other types as well.

https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-search-cancel-button
https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-search-results-button

Like this;
https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-inner-spin-button

Others;
https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-elements

[AykutSarac]

@AykutSarac Good question. I'm not sure. What kind of consequences do you predict? Do you mean considering to use a relevant icon while we use search input?

We need to show our own icons, so we have to create the functionality for displaying and clearing them. However, this component might be more complicated than we think. It's important to decide what we expect from a search input, as new modifications later could cause problems with the architecture.

[muratcorlu]

MDN says:

<input> elements of type search are text fields designed for the user to enter search queries into. These are functionally identical to text inputs, but may be styled differently by the user agent.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/search

Currently we use text type with search icon to show a search input:

<bl-input type="text" icon="search" ...></bl-input>

Since technically there is no behavioral diffierence between text and search types, we may only consider to set a default icon per type (also for datetime, for example) to provide a better consistency throughout all projects that uses Baklava.

<bl-input type="search"></bl-input>  <!-- comes with search icon by default -->

But, with the multiple icon registry support, this may be more confusing and tricky. Because search icon can be named differently in other icon libraries. (It's magnifying-glass on fontawesome icons, for example) But on the other hand, we already use default icons in many other places (info icon on tab component and alert component, exclamation icon on input error states, etc.) so this needs to be addressed anyway for other places as well.

So, considering we already have datetime type without a default icon applied, I don't see a big difference here. We already planned to have date picker component but in the meantime we thought it's ok to just being able to set datetime type for input to just have native browser UX for now, without waiting to implement date picker. They seem very similar to me.

[AykutSarac]

#713 will bring the icons for input types so we don't need to cover here. Do we have any TODO(s) for this PR anymore? @muratcorlu

[0o001]

#713 will bring the icons for input types so we don't need to cover here. Do we have any TODO(s) for this PR anymore? @muratcorlu

2056ca3

Perhaps you can consider this part.

[muratcorlu]

Yeah, we can consider this as a refactor proposal. @0o001 If you can rollback the input type addition from this PR, we can consider and merge this separately.

[muratcorlu]

Thanks for your contribution @0o001 🚀

[github-actions]

🎉 This PR is included in version 2.3.0-beta.8 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 2.3.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀