Closed paritosh149 closed 6 years ago
Hey, thanks! I am planning to create Single File Component with plugin for Parcel and Webpack. Need to first figure out the best developer friendly syntax :)
I have been a Vue supporter since late 2015 when it had 12,000 stars and nobody was sold on it yet, and I really love how Vue has handled most things. I wound up leading a React career, though, so I do have experience with both.
As it pertains to syntax, regardless of SFC or not, I believe that JSX is the better option than a custom solution.
It combines actual JavaScript with a markup that is extremely similar to HTML, which makes complete sense when the goal is literally to combine JavaScript and HTML.
It doesn't introduce any new abstractions for developers to study/learn simply for templating, as JSX is the most widely used templating "language" among modern UI developers.
It doesn't require labor to invent something completely new if there is no agreement that something new is needed.
It allows developers to utilize the somewhat-vast ecosystem of JSX plugins already in existence. (jsx-control-statements, for example.)
Also, I really never liked handling logic in strings in Vue templating syntax. 0% intuitive or natural, and just didn't sit well with me.
It seems like JS-in-HTML has needed tons of solutions over the years. Handlebars, Mustache, Jade/Pug, Jinja, Jinja2, ERB, etc, etc, etc. But I don't think you can really do any better than JSX at combining the two.
-- I believe JSX with some built-ins for control flow would be amazing.
I agree wholeheartedly, but I do like the fact that we're supporting hyperscript as well.
My vote goes to keeping examples, docs etc,... in JSX though. Unification.
@ambewas The JSX compiles to the r calls if that's what you mean with hyperscript.
I've spent the last day or so working on a POC for builtIns
via JSX.
Basically, this:
<!-- Not an existing HTML element. -->
<something someProp="foobar">
<p>stuff</p>
</something>
becomes this:
r('something', { someProp: "foobar" }, [ r('p', null, "stuff") ]);
So my implementation went along the lines of this:
// builtIns.js
/* usage:
<animated>
<p>whatever you want</p>
</animated>
*/
export const animated = ({ props, children }) => {
return (
<div data-radi-builtIn className="animated rollIn">
{children}
</div>
);
};
export const builtIns = {
animated
}
Then createElement
...
export const createElement = (element) => {
// if element.tag is a string, check it against builtins
element.tag in builtIns && element.tag = builtIns[element.tag]
}
It is a bit rough right now, because handling/merging the props and such is a pain. But I do have this working.
New SFC component syntax is available in master. Also you can play around with it in our repl https://radi.js.org/#/fiddle
Great work. I liked the approach of completely missing out the VDom. I have been working with VueJs and keeping an eye on MarkoJs. VueJs has very good over all development ecosystem components in its repo. MarkoJs too has a very good approach on SFC. So, I request that SFC feature be considered to be included in Radi.js.