Best practise to use hyperscript #434

codart1 · 2021-05-01T16:50:32Z

codart1
May 1, 2021

https://codesandbox.io/s/solidjs-4k0c3?file=/index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Static Template</title>
    <script type="module">
      import {
        createSignal,
        createMemo,
        onCleanup
      } from "https://cdn.skypack.dev/solid-js";
      import { render } from "https://cdn.skypack.dev/solid-js/web";
      import html from "https://cdn.skypack.dev/solid-js/html";
      import h from "https://cdn.skypack.dev/solid-js/h";

      const Test = ({ devine, ...props }) => {
        return [h("h1", props), h("h2", () => devine())];
      };

      const App = () => {
        const [count, setCount] = createSignal(0),
          timer = setInterval(() => setCount(count() + 1), 1000);
        onCleanup(() => clearInterval(timer));

        const devineBy2 = () => count() / 2;
        return [
          h(Test, { foo: "bar", devine: () => () => devineBy2() }, () => () =>
            `count: ${count()}`
          ),
          h("a", { href: "#" }, "link"),
          h("ul", { bar: "baz" }, h("li", "li1"), h("li", "li2"))
        ];
      };
      render(App, document.body);
    </script>
  </head>
  <body></body>
</html>

Hi, I'm still learning this awesome library. This time I'm trying to optimize the rendering myself by using hyper script. Given the code sandbox above. I wonder why I have to wrap my signal in a double arrow function, like this: devine: () => () => devineBy2() to make it works.

What is the right way to make sure we will only render the part which will be changed?

I found hyper script is cool since it's just normal javascript. But as shown in your documentation, it's the slowest, how can I leverage it and minimize this downside?

ryansolid · 2021-05-02T04:19:20Z

ryansolid
May 2, 2021
Maintainer

There is a bug here. I mean there are some mistakes in the code as well but this example helped me find a bug with passing props objects straight to children.

A couple things to know. We keep all the conventions from JSX here, as in props get transformed into getter objects or proxies. It looks for functions to do so which is why you ended up having to wrap so deep. The idea is you'd just use () => props.derived and not be trying to call it as a function. Removing that did reveal this other bug. I will work on a fix for this.

But as shown in your documentation, it's the slowest, how can I leverage it and minimize this downside?

Not really. The problem isn't that it is slow. It's still one of the fastest approaches out there comparable to the fastest VDOM libraries.. only ~15% slower than JSX. But it just can't be optimized in the same way I can with a compiler. More so you are forced into being conscious of the reactive wrapping since I can't just compile it in.

The trickiest part is I've been trying to build this tool so that precompiled JSX components play along as well. Basically you get full access to the ecosystem, but the conventions are definitely more awkward.

I think I need to make a call whether this is good enough to be core or whether it's more of an experimental side thing. The experience does feel a bit compromised even if functional.

3 replies

codart1 May 2, 2021
Author

Yeah, glad it helps you found the bug accidentally.
I found using this style of templating help me understand solid better and since I'm willing to use it in my toy projects thus it's not a big deal at all.
In addition, being working without to be compiled is a beautiful thing to my eyes. I can leverage the modern esmodule whenever I want. It just dead simple.
For the performance critical stuffs. I will stick with the jsx solution.
Do you consider to support this use case, or will it be an experiment side thing forever?

ryansolid May 2, 2021
Maintainer

That's what I'm sort of debating. Unlike most "JSX" libraries this is like a completely different templating language. As is the Tagged Template Literal, which can do most of the JSX optimizations at runtime. So it means supporting 3 templating engines. Vue does this to be fair, but it definitely just requires some time and love. Once in place probably not that hard to maintain but I just have more some work to do up front and it is really hard to prioritize.

I was thinking of pulling these out being tied to the same version of the core runtime it doesn't make a ton of sense. Just probably be prepared for bug fixes. I don't expect breaking changes just I know it is less tested. I can do something about that atleast.

codart1 May 2, 2021
Author

Thanks Ryan. I know it will take a lot of efforts, even for a smart person like you.
I'm still on the road to understand how the machine work under the hood. Hopefully in the near future, I will be able to contribute back to this library.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Best practise to use hyperscript #434

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment 3 replies

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

Best practise to use hyperscript #434

codart1 May 1, 2021

Replies: 1 comment · 3 replies

ryansolid May 2, 2021 Maintainer

codart1 May 2, 2021 Author

ryansolid May 2, 2021 Maintainer

codart1 May 2, 2021 Author

codart1
May 1, 2021

Replies: 1 comment 3 replies

ryansolid
May 2, 2021
Maintainer

codart1 May 2, 2021
Author

ryansolid May 2, 2021
Maintainer

codart1 May 2, 2021
Author