Marcisbee / radi

🌀Tiny (in size) front-end framework with no extra browser re-flows
https://radi.js.org
MIT License
948 stars 34 forks source link

Feature request: SFC similar to Vuejs or Marko.js #1

Closed paritosh149 closed 6 years ago

paritosh149 commented 6 years ago

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.

Marcisbee commented 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 :)

colshacol commented 6 years ago

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.

  1. 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.

  2. 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.

  3. It doesn't require labor to invent something completely new if there is no agreement that something new is needed.

  4. 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.

ambewas commented 6 years ago

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.

rafaelklaessen commented 6 years ago

@ambewas The JSX compiles to the r calls if that's what you mean with hyperscript.

colshacol commented 6 years ago

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.

Marcisbee commented 6 years ago

New SFC component syntax is available in master. Also you can play around with it in our repl https://radi.js.org/#/fiddle