Setting inline style?

[dmitriz]

I have tried to set {style: {color: 'blue'}} inline in the simple example:

  yield div(
  	{style: {color: 'blue'}}, 
  	[
    	    "The address is ", 
    	    map((b) => b ? "valid" : "invalid", isValid)
  	]
  );

which worked but generated some errors in the console:

ERROR in ./index.ts
(13,4): error TS2345: Argument of type '(string | Maybe<"valid" | "invalid">)[]' is not assignable to parameter of type 'Child<string | Maybe<"valid" | "invalid">>'.
  Type '(string | Maybe<"valid" | "invalid">)[]' is not assignable to type '() => Iterator<Component<any>>'.
    Type '(string | Maybe<"valid" | "invalid">)[]' provides no match for the signature '(): Iterator<Component<any>>'.
webpack: Failed to compile.

Despite of the last statement, the color was actually changed (after the necessary manual reload).

---

On a more general note, you seem to be using the new custom element library. Would it work with snabbdom and other libraries?

On even more general note, I wonder what be your opinion on https://github.com/uzujs/uzu/issues/2

[paldepind]

I think what you're reporting is a bug in the types. They are too restrictive somehow. I will look into it.

On a more general note, you seem to be using the new custom element library. Would it work with snabbdom and other libraries?

That depends a bit on what you mean with "work with". A Turbine Component is essentially just a function that takes a parent DOM element and adds itself as a child to the DOM element it is given.

This means that a Turbine component works only with plain DOM. It should be possible to wrap our components so that they can be used in other frameworks. We only require that the framework can give access to raw DOM elements and provides some basic lifecycle hooks (most frameworks satisfy this). These wrapper-functions would have to return framework specific components. Inside they will just run the Turbine components they wrap.

We have specifically thought about creating such wrappers for Angular 1 and React. Doing it for Snabbdom would definitely be possible. The API could look a bit like this:

const snabbdomComponent = convertToSnabbdom(turbineComponent);

So what I'm talking about is some "adapter" function that converts Turbine components to other frameworks component format. Is that would you where thinking about?

I think Turbine is specifically well suited to this sort of wrapping because they can be completely self-contained.

[dmitriz]

I think what you're reporting is a bug in the types. They are too restrictive somehow. I will look into it.

I see. But if these are just types, is it perhaps possible to compile and run without typechecks, then those errors would go away?

On a more general note, you seem to be using the new custom element library. Would it work with snabbdom and other libraries?

That depends a bit on what you mean with "work with". A Turbine Component is essentially just a function that takes a parent DOM element and adds itself as a child to the DOM element it is given.

I see what you mean, I still would like to understand why you said you prefer dealing with DOM directly rather than with vdom.

This means that a Turbine component works only with plain DOM. It should be possible to wrap our components so that they can be used in other frameworks.

We only require that the framework can give access to raw DOM elements and provides some basic lifecycle hooks (most frameworks satisfy this). These wrapper-functions would have to return framework specific components. Inside they will just run the Turbine components they wrap.

That would be really great and very useful!

It is very similar with what I am attempting in un, except that it goes in the opposite direction -- to let you specify the vdom library or framework as parameter. That way people can continue using the same library syntax they are already using, which, unfortunately, differs even among the hyperscript libraries, see e.g. the discussion in hyperhype/hyperscript#66 .
However, it also makes the components less "universal" in that you can't always switch the dom libraries unless the only api you are using is supported by both.

With your adapters, it would make the components truly "inter-frameworkable", but of course, there is the extra cost of writing and maintaining the corresponding adapters.

We have specifically thought about creating such wrappers for Angular 1 and React. Doing it for Snabbdom would definitely be possible. The API could look a bit like this:

const snabbdomComponent = convertToSnabbdom(turbineComponent);

Angular 1 is a great idea. People are still using it a lot but have hard time bending it into the modern paradigms. So having such an adapter to use it with Angular should make a great resonance.

So what I'm talking about is some "adapter" function that converts Turbine components to other frameworks component format. Is that would you where thinking about?

Yes, pretty much. Also I'd find it useful to have them both ways. For instance, I really like the Mithril's hyperscript flavor that I find slightly less verbose, so I would prefer to use it when writing the vnodes e.g. with Turbine. Would it be easy to do?

I think Turbine is specifically well suited to this sort of wrapping because they can be completely self-contained.

Sounds great ;)

[paldepind]

I see what you mean, I still would like to understand why you said you prefer dealing with DOM directly rather than with vdom.

Yes! I have not forgotten you asked about this. I just need the time to provide a proper answer 😅

[paldepind]

The bug reported here turned out to be a problem with the types in Jabz. I've fixed it in Jabz and the problem should go away once Jabz is updated.