foxdonut / seview Goto Github PK

See discussion in #1 as per @futurist

I think it would be something like this?

type element = object;

type transformFn = (node: any) => element;

export function sv(transform: transformFn, options: object): h;

type h = (tagname> string, props: Prop, children: element[] ) => element;

Like m('') -> <div>, can add an option as below:

sv(func, {emptyTag: 'div'})

So ['', 'Hello'] result in <div>Hello</div>

Is it make sense?

In react iterable as children is valid:

    const element1 = (
      <React.Fragment>
        {new Set([<span key="a">hi</span>, <span key="b">bye</span>])}
      </React.Fragment>
    );

should review support iterable instead of only Array?

I just found this library (if it's possible to call it a library), I always found jsx annoying: https://stackoverflow.com/questions/44018839/why-not-simple-function-calls-instead-of-xml-tags-for-react-components
Because:

1. It introduces a new syntax that should be added to auto-complete engines, highlighter engines, linter engines, etc different editors. And should be learnt.
2. It is ugly and therefor not "easy to reason about": why should I write the name of almost every component I use twice (), Why should I have useless greater-thans and less-thans all over my code? Why should I use curly braces all over my code whenever I need to write js code?

Considering that QML was born 4 years before React, and considering that it has none of above problems I wonder why they didn't search other's work in the area before inventing something ugly like JSX.

I used React since its early days and I observed how it evolved, I saw all the trial and errors they did and it was obvious for me that this product is anything but well-engineered, again they could just watch QML as a perfectly engineered reactive framework and learn from it.

But despite all these issues and their ugly syntax React got the dominant framework for web developers with Facebook boosting and advertising the project, the company that has its biggest product written in PHP. It was a good thing considering the ancestors of React like Angular and jquery, it was indeed a step forward, it improved the standards and the quality of web and reduced the cpu power and electricity consumed by clients to render web applications. But it always annoyed me that this ugly language and this made of trial and error framework is the dominant framework for web developers and there's no framework that can compete with it, after all we all agree that it was a big step forward from the jQuery and Angular era.

The framework is now mature enough but the problem with the language still remains.
I was always wishing I had the time to make a transpiler that translates QML like code to React but unfortunately it never happened. Now today I saw this repository and I think it's even better than what I was wishing to accomplish while much more lightweight.
Consider this JSX construct:

<Component prop1={value_1} prop2={value_2} ... propn={value_n}>
    <Child_1 .../>
    <Child_2 .../>
    ...
    <Child_n .../>
</Component>

The QML equivalent would be:

Component {
    prop_1: value_1
    prop_2: value_2
    ...
    prop_n: value_n
    child_2: Child_2 {
        ...
    }
    child_3: Child_3 {
        ...
    }
    ...
    child_n: Child_n {
        ...
    }
    Child_1 {
        ...
    }
}

No more annoying less-thans nor greater-than's nor slashes. No more annoying curly braces for each value. No ambiguity about children being an object or an array. And easy to read and easy to reason about.
And the seview equivalent is almost the same:

[Component, {
    prop_1: value_1,
    prop_2: value_2,
    ...
    prop_n: value_n,
}, [
    [Child_1, ...],
    [Child_2, ...],
    ...,
    [Child_n, ...],
]]

No more annoying less-thans nor greater-than's nor slashes. No more annoying curly braces for each value. Still there's the same ambiguity about children being an object or an array but it's something that should be handled in underlying view and after all not a big problem. Easy to read and easy to reason about. It has few advantages over QML and JSX syntax: the component itself can be any js construct (In QML you should put a name of a component there, you can't put a function call that returns a component for example.) Another advantage is it's written in bare js, no need to transpile with babel, no need to write auto-complete engines, etc for all editors out there and no need to learn a new language.

So I'm really thankful for your time for introducing this.
I have a minor suggestion about your library, I think maybe you can avoid constructs like input[name=username][required]. I mean to keep it lightweight, explicit and "easy to reason about" maybe it's better to avoid having multiple ways to set attributes and just keep all the attrs in the object passed as second argument. It introduces complexities like this:
What if I pass an attribute both as a css selector in the first element of array and as an item in the object passed as the second element of array?

Another thing would be to avoid different array constructs like [Component, attrs, children] and [Component, children] it also introduces complexities.

I think by avoiding these 2 constructs we'll have a lighter library with less complexity and maybe we reach to a point that the codebase is so simple and straightforward that instead of being installed as an npm package can be copy pasted to a file and instead of hosting on a git repository can be host in a gist. (I'm not sure these 2 are good ideas, actually I think it's better to keep it as an npm package and as a git repo, but I just wanted to emphasize on how light-weight it'd be.)

P.S. I also read your post about avoiding Redux and MobX and I'm super fond of it. I'm really thankful for the time you spent to improve web-development patterns.