JSX support for Views about cyclejs HOT 17 CLOSED

https://github.com/alexmingoia/jsx-transform looks useful.

from cyclejs.

Correct @guersam, I had jsx-transform in mind. In theory, it can already be used in combination with Cycle, but this feature #35 would maybe include it as a hard dependency and/or consider web components instead of translating <HelloWorld> into HelloWorld().

from cyclejs.

@staltz, I posted a proposal to @alexmingoia to update syntax to account CycleJS case.
He says he plans to implement that soon, so no need to fork.

from cyclejs.

Great!

from cyclejs.

alexmingoia/jsx-transform#14 closed. This works now:

let View = Cycle.createView(Model => {
  let width$ = Model.get("width$");
  return {
    vtree$: width$.map(width => (
      <Slider width={width}/>
    )),
  };
});

👏 @alexmingoia

from cyclejs.

👍

from cyclejs.

jsx-webpack-loader updated to support this as well now.

from cyclejs.

I'll leave this issue open until we have good "getting started" (with JSX) docs.

from cyclejs.

For completeness: If one uses babel already one can use it's JSX transform. For that to work needs a little work around because the virtual-dom library expects exactly 3 arguments where the last one is an array of children. However, Babel's JSX transform creates an h call with 2 + number-of-children arguments. To work around this problem, add this "pragma" comment to specify a custom dom creation function:

/** @jsx dom */

and then add this helper method:

function dom(tag, attrs, ...children) {
  return h(tag, attrs, children);
}

from cyclejs.

I think the right way to do this now is with a Babel plugin.
Babel has released plugin API in 5.0: https://babeljs.io/docs/usage/plugins/

@sebmck How hard it is it to plug another interpretation of JSX with a plugin API?

from cyclejs.

Thanks @danyx23 good to know about that. Actually I'd rather recreate virtual-hyperscript (i.e., fork it and adapt it), than make another wrapper adapter (this dom()). That would be quite convenient, also because virtual-hyperscript has things we don't need, such as ev-click handling.

from cyclejs.

Yes, and perhaps to workaround the issues they won'f fix: Matt-Esch/virtual-dom#228

from cyclejs.

@Gaeron Oh neat, I didn't know about that, will look into it!

@staltz That might be a good idea in any case, as virtual hyperscript is a bit problematic in some edge cases. In my BMI example the sliders fail to take the correct position initially if they set the value outside the default range of 0-100 and the ranges are set accordingly. The problem is that the order of setting the dom properties/attributes is crucial (range has to be set before value for it to work), but as virtual hyperscript passes properties and attributes as an (unordered) object one has no control over the order of application. The way to solve this with vdom ATM is to add hooks to sort out the order, but this is of course an implementation detail that should be hidden somewhere. A vdom fork would be a good place for that. (I see @ivan-kleshnin just chimed in referencing the same issue :) )

from cyclejs.

Yes, and perhaps to workaround the issues they won'f fix: Matt-Esch/virtual-dom#228

Yeah I've been following that issue, and yes it would make sense to do that in a custom Cycle virtual-hyperscript. I wouldn't want to fork virtual-dom since that would double the amount of work I need to do, but we can try finding a work around for this.

from cyclejs.

@gaearon More than possible. By default plugins are ran before all the internal transformers so you have access to the raw JSX AST that you can do whatever with.

from cyclejs.

Sounds ideal, and I'm more interested in doing JSX internally in Cycle than to make it an external dependency or the developer's own responsibility. And we are already using babel in Cycle src/ so makes sense to make a babel plugin.

from cyclejs.

This issue was moved to cyclejs/cycle-web#7

from cyclejs.