Follow web components specs about yew HOT 11 CLOSED

I'm sorry, I mixed two concerns in my comment.

1. If Rust has any equivalent to JS template literals, I would suggest using that instead of using a non-standard language (JSX)
2. Map the web component APIs to Rust instead of creating a component model in Rust that tries to mak its own component model. We don't need Angular, React, Vue, Ember, and any other frameworks to keep implementing a component model. Yew creating a component model would be the same thing. All of these frameworks should be building on top of web components or ceasing to exist since web components are doing a large part of what the frameworks are doing

from yew.

After reading through my earlier comments and thinking about this a bit, I would like to clarify my earlier points in case they weren't clear.

IMO, I think it would be wise to consider exposing the base web components APIs as directly as possible, starting with and focusing on the custom elements API. A Yew component should be an HTML custom element, a DOM object. It should have all of the lifecycle methods of a custom element. It should be a DOM object under the hood. Any conveniences, like automatic getters and setters, can be built on top. This is what I would love to see.

We probably need to wait on WebAssembly to mature a bit, especially waiting on access to the DOM from WebAssembly

from yew.

Good points, I'm just advocating the use of web components wherever plausible in this library to maintain maximum compatibility and modularity. I want to be able to use components written with yew in any framework or library

from yew.

IMO having custom elements with shadow DOM would be a killer feature, as it would allow for an effective data hiding with HTML classes and IDs. I'm still new to Rust, but I'd like to help implementing that if someone with more experience jumps on the issue.

from yew.

What is component model vs Rust component model for you?
Are you talking about JSX (No necessarily React) vs String Template Literals ?

from yew.

@lastmjs here is my two cents.

Web Component Specs

Keep in mind that Web Components is 4 things

• Template tag
• Custom Elements
• Shadow DOM
• HTML Import

I am guessing that you refer ro the Custom Element piece of it.

Anyway,

I will talk from what we have right now and forget Rust for a moment because it doesn't really matter the language but the architecture of it.

JSX vs Template Literal

JSX doesn't have to be React specific tool, in fact, you could use the same syntax for generate JSON structures, strings or any other data structure that is not React elements. Because JSX right now it is just a syntactic sugar code.

I wouldn't use it, because if you use String instead of some syntactic sugar you will have to parse the string back to some data structures so you could do more advance operation with the AST.

Keep in mind the whole spectrum of things around it, for example, now React uses JSON for do testing rather than render any HTML (super mega valuable) and so on.

Working with Strings will makes harder to create tools, tools that save you time and improve your workflow, using standards or not do not matter because if that is the case projects like Babel (thanks God that we moved with it), Typescript, Flow, JSX and any of those non-standard tools would exists, right?!

Even that, right now jew uses html! { ... } macro, which inside is just as template literals but without the quotes 😊 right?! What is the different between JSX and Template Literals anyway from syntax perspective?! quotes?! Meh, it is Rust no Javascript anyway.

React/Vue/Angular Component vs Custom Elements

I don't see that a something fundamentally different, I am actually waiting for the day I will use Custom Elements + React/Angular or whichever one.

The boilerplate required for it is too much, probably you are unaware if you use something like Polymer and those libs.

Without those libs you will have to maintain setters and getters and DOM manipulation everywhere in your code.
When you have a model as the current state on the web, you do not need to pay attention to your DOM manipulation but your data.

That is something really valuable, DOM manipulation is always hard to get it right specially when you talk about performance details that you get for free in libs like React.

Right now the current model will work with anything from Web Components without any problem, because Web Components spec do not collide with anything from React/Angular/Vue or any other framework.

I am still no understanding exactly what you mean, but if you refer to how we define components, to be honest, it doesn't matter and you are using Rust that have nothing to do with Javascript anyway 😄 The final output could be Web Components or whatever you decide to be.

from yew.

Sounds like that is the plan? If so, awesome, and thank you for your thoughts

from yew.

Which part of Web Compornents?!

If you are referring to Custom Elements that is not problem at all as it is, neither React or any other lib we do not use it in such of libs because Shadow DOM is not 100% and neither Custom Elements and HTML Import is on hold .... but that have nothing to do in how you write your components. I can use React based components inside my Custom Element

from yew.

Okay, thanks for all of the thoughts. Will Yew have first-class support for the custom elements spec? Custom elements is v1 stable, is implemented in Chrome, FireFox, Safari, and Edge is working on it. The polyfills are excellent for Edge in the meantime. Shadow DOM would be nice eventually, but I don't think it's as important to implement as custom elements, in terms of priority at least. Templates are already implemented essentially everywhere. There is no need for HTML imports, they're done, the community has moved on to ES modules and I believe that is working well for most everyone.

So, will Yew support the following?

• custom elements v1
• shadow DOM v1
• ES modules

The most important thing to me is if I'll be able to author custom elements in Yew, and consume custom elements with Yew.

from yew.

After doing some research on this I've found out this.

1. In order to implement a custom element, one must inherit from browser-native HTMLElement using prototype inheritance;
2. Right now there is now way to describe prototype inheritance using RustWASM. There is an RFC and a PR with POC implementation (rustwasm/rfcs#11), but judging by the discussion, this issue turned out to be a lot more complex than expected. TL;DR: smart folks over at RustWASM are working on it.

from yew.

Missing label:

• proposal

from yew.