virtual-dom-rs fails to compile on stable

[johnpmayer]

This is despite https://github.com/rustwasm/wasm-bindgen/issues/1283

I think that the requirement can be removed from https://github.com/chinedufn/percy/blob/master/crates/virtual-node/Cargo.toml

I'll give this a shot locally and open a PR if it's working

[johnpmayer]

The nightly feature can be removed from wasm-bindgen, but it seems that use of the proc_macro_hygiene feature in virtual-dom-rs still required nightly

[johnpmayer]

I suppose nightly is still required until https://github.com/rust-lang/rust/issues/54727

[johnpmayer]

https://github.com/chinedufn/percy/compare/master...johnpmayer:master

Proof concept that the code can be built on stable when the macro is taken out. It seems that there are two bits where the macro is used in virtual-dom-rs:

1. Re-export the html macro in the prelude
2. Heavy use of the macro in test code

The test code could be moved, but I wouldn't seriously propose conditionally excluding stuff from the prelude on the stable branch.

Would you be open to a PR that decomposed this codebase into a virtual-dom-algo which pulled out the diff and patch algorithms and tested them without use of the procedural macro?

[chinedufn]

Thanks so much for looking into this!

There are of course multiple ways to go about this ... but I do like splitting out a crate for the virtual dom algorithm since over time we want people to be able to easily grab just that piece to go off and do whatever they please (i.e. in the future the algorithm takes in trait objects instead of VirtualNode.)

---

So this sounds great - but heads up that a few chapters in the Internal Design chapter of the book reference the code so might need to change a couple of links.

A quick grep or whatever for virtual-dom-rs in the book/src directory should do the trick.

Example -> https://github.com/chinedufn/percy/blob/792b4e412cec19d09bdca0c601a117cfe8dd86ad/book/src/diff-patch/diff-patch-walkthrough/README.md

--

Excited for better stable support!

Out of curiosity - what prompted you to notice and want this? Just so that myself and anyone reading this issue gains a better understanding of how the libraries are being used / considered!

[johnpmayer]

Regarding my motivations:

• It's a personal preference of mine to stay on the stable toolchain; I don't want the rug pulled out under my project if the feature is deprecated and I can't can't keep libraries up-to-date
• I'm not ready to take on a full framework, and was looking around for a standalone virtualdom library that supports SVG

At this moment I'm actually looking at https://github.com/fitzgen/dodrio

Meta point - I am not aware of a centralized review of all of the existing virtual dom implementations (there are a handful) and the trade-offs between them. In addition to Percy, the Yew and Squark frameworks also have their own virtual dom implementations. I have not done any deep investigation to see whether any particular implementation merits more attention than others. I can imagine that there are a handful mutually-incompatible of technical choices between the various implementations which would make one library more fit for purpose than another for different workloads; though in the absence of such differences it may be economical to all use a common implementation.

[dbrgn]

Here's another use case: I'd like to move https://github.com/threema-ch/compose-area over to stable. I think all dependencies are compatible with stable, but virtual-node (through virtual-dom-rs) enables the nightly feature on wasm-bindgen.

[chinedufn]

@dbrgn virtual-dom-rs = "0.6.12" should work on stable - let me know if there are any issues!

https://github.com/chinedufn/percy/commit/1b5d8aa70defdda58a135fe2b5f99a8d99f55b56