feat: add attributions for crates

.vscode/spellright.dict

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

docs/guide/src/helpers/index.md

@@ -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
+
+

docs/guide/src/state/liftingstate.md

@@ -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.