* Add `#[component]` attribute + system for creating component attributes + other stuff
* Delete inlineprops.rs
* Update inline_props.rs
* Cargo fmt
* Fix clippy warnings and paths in props/mods.rs
* Include where clause in `#[inline_props]` output
* Allow Clippy type complexity in `LinkProps`
* Allow the type complexity lint for the entire link.rs file
* Remove snake_case -> PascalCase converter, but rather enforce PascalCase
Also:
- Put the second function inside the main one instead of besides it.
- Simplify
* Simplify type check lints so they don't return false positives
They will not always work, but they won't return any false positives, like for aliases. This is likely going to be replaced by a more polished Clippy-backed linting system.
* Fix#583
* Cargo fmt
* Add docs for `deserialize()` and remove useless comment
* Add `#[component]` to prelude
* Merge branch 'master' of https://github.com/tigerros/dioxus
* #[inline_props] is no more. Except in the docs folder, but that's going to be removed
* Remove docs folder
* Remove docs from workspace
* Resolve `DeserializerOutput` conversation
This commit adds subtree memoization to Dioxus.
Subtree memoization is basically a compile-time step that drastically
reduces the amount of work the diffing engine needs to do at runtime by
extracting non-changing nodes out into a static "template." Templates
are then understood by the various renderers in the ecosystem as a
faster way of rendering the same items.
For example, in the web, templates are simply a set of DOM Nodes created
once and then cloned later. This is the same pattern frameworks like Lithtml
and SolidJS use to achieve near-perfect performance.
Subtree memoization adds an additional level of complexity to Dioxus. The RSX
macro needs to be much smarter to identify changing/nonchanging nodes and
generate a mapping between the Template and its runtime counterparts.
This commit represents a working starter point for this work, adding support
for templates for the web, desktop, liveview, ssr, and native-core renderers.
In the future we will try to shrink code generation, generally improve
performance, and simplify our implementation.
