Fixed custom elements patching, Added El::is_custom()

[MartinKavik]

#325

Custom elements (like code-block on seed-rs.org) have to be recreated, we cannot manage their content directly (i.e. we can't patch them like the built-in elements).

We should try to find a better solution and write tests once there is a solid Rust wrapper for WebComponents.

Tested with seed-rs.org project connected to modified local Seed repository.

[MartinKavik]

@David-OConnor Merge branch 'master' into fix/custom_el_diff => is there a button you are clicking? 😄 I don't want to have commits like master merged into custom_el_diff in master history, so I like to rebase my working branch onto master on my local machine and then force-push working branch.

[David-OConnor]

Yeah; I think it's resolve conflicts. It opens up an editor where you can fix merge conflicts in GH; Ie I hit the button, fixed the changelog, and hit OK.

[akhilman]

Just tried a custom element and found it strange that seed resets the internal state of the element. I need to investigate more, but I think that patching the attributes of custom elements is the way to go.
The problem with the code-block can be solved with el_key #354 #357 when it ready.

[MartinKavik]

@akhilman Yes, resetting internal state was basically a workaround for badly written custom elements and some other weird behavior which I don't remember. I had to resolve it quickly because it was breaking Seed website (seed-rs/seed-rs.org#19).
To revert this, remove old.is_custom() from

seed/src/virtual_dom/patch.rs

Line 30 in 5e61a6e

if old.tag != new.tag || old.namespace != new.namespace || old.is_custom() {

and web component in seed-rs.org repo should be rewritten to get source code from its attribute instead of its content, so Seed is able to patch it correctly - https://github.com/seed-rs/seed-rs.org/blob/master/web_components/code-block.ts. (I've already rewritten it into JS so rewritting to TS should be enough - https://gist.github.com/MartinKavik/713dd5251330e565128b443058d2a5e8)

[akhilman]

I think I have a better solution then pushing code to element's attribute.

Take a look at https://stackblitz.com/edit/r1xj6g. Here I use a mutation observer to detect if inner html of the custom element has changed.

[MartinKavik]

Can be, I chose the first and the simplest/shortest solution. And attribute observer is built-in + you get property accessors for free so there is small chance to introduce bugs.
However your approach has more elegant public API, because we don't need to assign long text to the attribute.

P.S. You can delete fallback for IE, because IE doesn't support WASM.