Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Props return strings #14

Closed
jayrbolton opened this issue Jan 30, 2018 · 5 comments
Closed

Props return strings #14

jayrbolton opened this issue Jan 30, 2018 · 5 comments

Comments

@jayrbolton
Copy link
Contributor

If I do the following, my input will be disabled:

html`<input @props:disabled=${false}>`
// returns the following:
{ sel: 'input',
  data: { props: { disabled: 'false' } },
  children: undefined,
  text: undefined,
  elm: undefined,
  key: undefined }

Notice it sets disabled to the "false" string, which is truthy, so I am unexpectedly disabled.

However, if I use an overall @props=${object}, it works as expected:

html`<input @props=${{disabled: false}}>`
// returns the following:
{ sel: 'input',
  data: { props: { disabled: false } },
  children: undefined,
  text: undefined,
  elm: undefined,
  key: undefined }

Now the disabled prop is correctly a real boolean, not a string.

@jayrbolton
Copy link
Contributor Author

related
choojs/hyperx#42

@jamen
Copy link
Collaborator

jamen commented Jan 31, 2018

Hopefully the hack works alright for your purposes. :)

I dont think there is anything else we would want to do from snabby that is sane. There is a proposed fix linked on that issue too.

(I stopped using hyperx because the apparent lack of maintenance and because the trickery to get a production build, which is why this package has gone kind of dormant, but I digress)

@jamen jamen closed this as completed Jan 31, 2018
@jayrbolton
Copy link
Contributor Author

Yeah it works for most use cases. A big downside is that undefined and null will still be truthy, for example if you do <div @class:x=${undefined}></div>, then undefined will be a string in the vnode. But this is more of a hyperx issue for sure.

Do you know if there are better alternatives to hyperx? Maybe the template string parser can be rethought / improved in another lib.

@jamen
Copy link
Collaborator

jamen commented Jan 31, 2018

I'm currently using hyperapp with good ol' h(name, data, children).

I'm not aware of any alternatives to hyperx. But here is some issues that I have with it:

  • You're forced to use hyperxify to produce h(). Not suited for Rollup in my new setups. Also forces Hyperx to parse the strings each time without hyperxify. I haven't done the benchmarks on this but I'm curious. Every state update sounds bad.
  • It preserves all whitespace so the output is NOT automatically minified. This is kind of subjective, but I found it unappealing for static things like .svg, .html, and I'm not aware of any issues relating to DOM/VDOM with this.
  • The syntax highlighting is awkward. JSX has decent syntax support (Emacs 😡), and h() is just a call and works the best.

I suggest h() or JSX instead. Maybe hyperx can be improved upon, but my logic is that if you have to compile your template strings you might as well use JSX or h() instead.

@jayrbolton
Copy link
Contributor Author

Thanks for the reply @jamen -- points well taken. I agree with what you're saying. I still like having a template string option for small projects with snabbdom. It might be worth putting these "gotchas" in the readme

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants