feat: add attributions for crates

This commit is contained in:
Jonathan Kelley 2022-03-08 14:41:49 -05:00
parent 3acd643afb
commit c6fdd03a9d
3 changed files with 48 additions and 2 deletions

View file

@ -79,3 +79,4 @@ clonable
oninput
Webview
idanarye
Katex

View file

@ -1 +1,47 @@
# Helper Crates
Because the Dioxus ecosystem is fairly young, there aren't a ton of third-party libraries designed to "get things done." That's where the Dioxus helper crates come in. These are officially supported crates built on top of existing libraries to solve some of the common barriers to building apps.
## Router
Quickly add a cross-platform router to structure your app.
https://github.com/DioxusLabs/dioxus/tree/master/packages/router
## Fermi
Global state as easy as `use_state`.
https://github.com/DioxusLabs/dioxus/tree/master/packages/fermi
## Query
This crate has yet to be developed! However, we do plan on providing a crate for good fetching and query support.
## 3rd-party - Toast
Toast notifications, curtesy of [@mrxiaozhuox](https://github.com/mrxiaozhuox).
https://github.com/mrxiaozhuox/dioxus-toast
## 3rd-party - HeroIcon
Collection of helpful hero icons, curtesy of [@autarch](https://github.com/autarch).
https://github.com/houseabsolute/dioxus-heroicons
## 3rd-party - Katex
Draw beautiful equations, curtesy of [@oovm](https://github.com/oovm)
https://github.com/oovm/katex-wasm/tree/dev/projects/dioxus-katex
## 3rd-party - PrimsJS
Highlight your code blocks with ease, curtesy of [@oovm](https://github.com/oovm)
https://github.com/oovm/katex-wasm/tree/dev/projects/dioxus-katex

View file

@ -104,8 +104,7 @@ fn Title(cx: Scope) -> Element {
This is great - all is well in the world. We get precise updates, automatic memoization, and a solid abstraction. But, what happens when we want to reuse this component in another project? This component is now deeply intertwined with our global state - which might not be the same in another app.
In this case, we want to "lift" our global state out of "view" components. With `lifting`, our individual components at "leaf" position of our VirtualDom are "pure", making them easily reusable, testable, and deterministic. For instance, the "title" bar of our app might be a fairly complicated component.
In this case, we want to "lift" our global state out of "view" components. With `lifting`, our individual components at "leaf" position of our VirtualDom are "pure", making them easily reusable, testable, and deterministic.
To enable our title component to be used across apps, we want to lift our atoms upwards and out of the Title component. We would organize a bunch of other components in this section of the app to share some of the same state.