Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Serge Havas
@Sinewyk
the probleme usually is for components
h(componentFunction, null, [])
but it doesn't support this apparently
Tylor Steinberger
@TylorS
Do you have a use case? I’ve just never needed it
Serge Havas
@Sinewyk
Well, it's just classic code, to avoid repetition
Like if you write react
Tylor Steinberger
@TylorS
It doesn’t seem like much more than componentFunction() that returns the view
Serge Havas
@Sinewyk
it is, it's just the difference between you yourself calling it
or your dom library doing it for you
<div><MyComponent/></div>
vs
Tylor Steinberger
@TylorS
I do use React and JSX at work, but we don’t use any class Foo extends Component so these things are a bit lost on me
Serge Havas
@Sinewyk
<div>{MyComponent()}</div>
Even if no classes
just props => <div/>
you don't support tagName being a function
typeof tagName === 'function' ? tagName(data, children) somewhere
and more precisely
typeof tagName === 'function' ? tagName(data === null ? {} : data, children)
to support destructuration
Tylor Steinberger
@TylorS
Yeah, I’m going to open an issue in mostly-dom for this
Serge Havas
@Sinewyk
It's just, my eyes are bleeding when directly manipulating hyperscript helpers, jsx makes it so much nicer IMO :)
Thanks for the talk =)
I'll try it soon =)
Tylor Steinberger
@TylorS
TylorS167/mostly-dom#50
Serge Havas
@Sinewyk
Nice, I would have added the special case that null needs to be transformed to {} to supports destructuration, since apparently all jsx transformers transform <Component/> to helper(Component, null, [])
Tylor Steinberger
@TylorS
:+1:
Serge Havas
@Sinewyk
Can I open a PR on this ?
Tylor Steinberger
@TylorS
Yes, that’d be great.
Serge Havas
@Sinewyk
Wow
Making that function polymorphic makes it so much harder haha
Serge Havas
@Sinewyk
I made a mistake
It's elm that has the h('div', data, []) API
jsx is h('div', data, ...children)
Serge Havas
@Sinewyk
The easiest thing to supports jsx would probably actually be to make a small wrapper for jsx
that then sends its arguments (reworked) to h itself
Kelly Thomas Kline
@kellytk
Pardon me if this isn't the correct channel for the suggestion, but I'd like to see something like most (or ReactiveX) Rx for Rust. Have you given any thought to that @tylors?
Frederik Krautwald
@Frikki
Hi @kellytk, I don’t understand what you’d like to see where. Motorcycle uses most/core streams.
Consider using libraries form this organization https://github.com/motorcycle
Brian Cavalier
@briancavalier
Hi @kellytk. Perhaps we could talk more about your question of most in Rust over in the cujojs/most gitter. Id be happy to share more info about most, if that would be helpful.
Kelly Thomas Kline
@kellytk
Thanks @Frikki and @briancavalier, I'll join that channel
Aron Nyborg Allen
@aronallen
Just reaching out to our fellow motorcyclists. Remember to secure your ticket to CycleConf 2018. We have sold about a third of tickets as of now. We would really like to see you in Copenhagen. Beginners and experts are equally welcome.
http://cycleconf.com
Marton Sari
@sarimarton
Hello motorcycle people. I'm just a random dude, who explores stream based UI building possibilities, and ended up in the Cycle.js community. Occasionally stumbled upon motorcyclejs, and I'd really like to know what motivates this framework? I see its logo being a reference to cycle.js, but I don't see any reference or distincting motivation in the description.
Srepfler Srdan
@schrepfler
IIRC it's a fork of cycle which uses most.js
Marton Sari
@sarimarton
Thanks, @schrepfler . Is it something about that xstream is supposedly cycle.js's weak point?
And what about the fact that Cycle.js has a mostjs runner, so in theory it could be used with cycle already?
Srepfler Srdan
@schrepfler
I can't say I'm certain but if my memory serves me at the time there was a lot of experimentation with the API. IIRC the most.js based fork was proposed from external community members and there wasn't any problem with that, it just validated the cycle design. The experimentation was a reward in itself, that kind of iteration allowed the community to learn which were the pain points of using rxjs move and hence xstream was born. These days I think he came up with callbags which is also interesting.
I just know the legend, I'm completely useless from a practical point of view about your question around the runner :D
Kelly Thomas Kline
@kellytk
What are the RxJS design weaknesses considered to be?
Srepfler Srdan
@schrepfler
a part from RxJS at that time was a bit chubbier than it is today, IIRC the main thing was that it supported both hot and cold observables and that was causing a lot of questions. I think the idea was that for UI kind of workloads eager is more easier to understand and use, hence xstream was born which only has hot streams (prominently shown on the main page)