fix: do not convert boolean to string

[damiennl]

Hello 👋,

I've just removed the boolean convert to string in order to write some JSX code like this:

<>
  {flash.has('error'} && <span>{flash.get('error')}</span>}
</>

Because it could shows false which is not expected

It is by the way a regression because it was the behavior in v3.1.2

Thx 🙏

[changeset-bot]

🦋 Changeset detected

Latest commit: 95de098

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@kitajs/html	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[arthurfiorette]

Hey @damiennl this was a regression of v3 because in v4 it now follows the exactly same behavior as React.

You implementation also ignores true which leads to other unexpected behaviors too

[arthurfiorette]

@JacopoPatroclo what's you thoughts on this?

[JacopoPatroclo]

@arthurfiorette The changes are sane. I agree with @damiennl that if you want to write something like this it's important that the boolean values are not rendered as strings. It makes the library more similar to React (and other jsx renderers) and I think it's a good thing.

I will also advise @damiennl to make sure to never put untrusted strings inside flash messages and/or escape them (using the primitive that this library gives you).

Thanks for the contribution @damiennl !

[arthurfiorette]

It was indeed a regression/breaking change, that's why we are at 4.0.0 now.

The only requirement is to follow what React does because React is a "baseline" for every JSX runtime. Does this regression follows react? If it doesn't then it's a bug and I'll merge this pr.

Can someone create a test / reproducible example so that we can test it out?

Kita/Html doesn't have to actually follow react, but I assume most of the devs who will try Kita/Html comes from a background with React and having different behaviors from React for simple thins such as how we transform values to html strings will be a bad thing long term.

I'm also open to new suggestions @JacopoPatroclo & @damiennl