Updates I've been wanting to push for a while, finally sat down and m…

…ade them from my bookmarks.

src/components/pages/State.jsx

@@ -102,7 +102,7 @@ export function GreenfieldContent() {
           <Step last>
             For extremely complex state, consider state machines like{' '}
             <Resource url="https://www.npmjs.com/package/xstate">
-              xState
+              xState (or the simpler @xState/xStore)
             </Resource>
           </Step>
         </StepList>

src/pages/automated-testing.mdx

@@ -122,7 +122,8 @@ Everything that you test that isn't "Visual" is probably going to fall in the "B
   - Controlled component interactivity - When components become "controlled" - they relinquish some of their internal state to the callee/parent. Typically, this is through the use of props and they would be named something like onClick, onToggle, onChange, etc. You should be testing that these props properly work and are called when expected and with the expected arguments if any are included.
 - Custom Hooks & Context Providers (Unit Tests)
   - As for testing a custom hook / context provider - it is recommended not to try to test the hook/context itself and instead consume the hook/context in a component for the sake of testing. The component can be one that's actually used in the application or is just a dummy component (that never gets loaded in the production bundle) for the sake of testing. Either way, writing a component to consume the underlying hook/context will be easier to test than trying to test just a hook/context in isolation.
-  - The point we want to drive home for you is that for your test of a hook/context - try to do it all in one component (dummy or real, it doesn't matter). Outside of the test, you should probably be _mocking_ your contexts everywhere else they are used (to make your other tests simpler to reason about).
+  - The point we want to drive home for you is that for your test of a hook/context - try to do it all in one component (dummy or real, it doesn't matter).
+  - On the idea of mocking contexts: is probably un-necessary for the most part. It can be useful sometimes to mock your context providers to return *specific* values if you need to test unit/integration behavior.
   - If you are insistent on testing custom hooks in isolation you can try this library: <Resource url='https://react-hooks-testing-library.com/reference/api'>React Hooks Testing Library</Resource>
 - Global Stores (Unit Tests)
   - Unlike the above, if you're using a library like Redux or Jotai, you CAN write some unit tests for your state logic. Any library worth using should probably have a page on how to write tests in said library, for example:

src/pages/frameworks/react-native.mdx

@@ -5,12 +5,13 @@ export const description =
 
 There's no reason you can't or shouldn't follow a directory-setup like we describe on our normal <Resource url='/project-standards'>Project Standards</Resource> page.
 
-## Limitations of React Native
+## Intro to React Native
 
-In 2018, Airbnb, longtime supporter (and consumers) of React Native shocked the community when they publicly announced they were sunsetting use of React Native on their mobile application products. The article is still published <Resource url='https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a'>here</Resource>, along with the <Resource url='https://medium.com/airbnb-engineering/react-native-at-airbnb-f95aa460be1c'>entire series</Resource> explaining the challenges they faced building an enterprise mobile application with React Native. We feel it is fair to recognize this pivotal moment in the history because it reoriented the focus of the React Native team - some of the identified gaps of which have been closed and others which are still being worked on. It's only fair to mention this so you can be more sure that React Native is the right choice for your application in the long-term.
+- <Resource url='https://reactnative.dev/docs/tutorial'>React Native Tutorial</Resource>
+- <Resource url='https://expo.dev/blog/from-web-to-native-with-react'>From Web to Native with React</Resource>
+- <Resource url='https://www.reddit.com/r/reactnative/'>reddit.com/r/reactnative</Resource>
 
-
-## Common UX Standards
+## Basic UX for Touch Devices
 
 **Cancellation** - Give your users the ability to "cancel" a touch/gesture right in the middle of it (for example, by dragging their finger away). Read more about gesture best practices <Resource url='https://reactnative.dev/docs/gesture-responder-system'>here</Resource>.
 

src/pages/fundamentals.mdx

@@ -37,6 +37,7 @@ The class of bugs you're getting rid of are all those pesky (…cannot read… '
 - <Resource url='https://www.typescriptcourse.com/why-typescript'>Why TypeScript?</Resource>
 - <Resource url='https://www.totaltypescript.com/tutorials/beginners-typescript'>Beginner's TypeScript</Resource> - A (free) interactive video course by Matt Pocock
 - <Resource url='https://www.totaltypescript.com/tutorials/react-with-typescript'>React with TypeScript</Resource> - Another free video course by Matt Pocock
+- <Resource url='https://www.totaltypescript.com/books/total-typescript-essentials'>Total TypeScript Essentials</Resource>
 - <Resource url='https://www.youtube.com/playlist?list=PLNqp92_EXZBJYFrpEzdO2EapvU0GOJ09n'>No BS TS</Resource> - A (free) video course by Jack Herrington
 - <Resource url='https://www.youtube.com/watch?v=30LWjhZzg50'>Learn TypeScript - Full Tutorial</Resource>
 - <Resource url='https://typescript.tv/errors/'>TypeScript errors</Resource> - How to fix your confusing TypeScript errors

src/pages/project-standards.mdx

@@ -283,5 +283,6 @@ It also prevents an entire class of bugs from arising, and gives IDE more capabi
 <Expand parent="Use JSDoc">
 Commenting systems like <Resource url='https://www.npmjs.com/package/jsdoc'>JSDoc</Resource> - technology like this assumes you write plentiful documentation in comments next to your code, and those same comments can be parsed to generate actual HTML webpages that you can navigate, view, etc. It basically tries to take all of your comments throughout your codebase and generate swagger-like documentation for it. If you did BOTH of the above options (1 and 2) this may not be necessary, but if one or both of the options above isn't viable for you then this may be helpful.
 - HTML pages are <Resource url='https://jsdoc.app/about-getting-started.html'>generated</Resource> by tracking your jsdoc comments and creating a navigable website (a type of documentation)
-- You may hear that you can "write TypeScript" with jsdoc comments, and while that is <Resource url='https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html'>technically true</Resource>, we find that writing *application* code that way can be counter-productive. Maintaining a library is a different story - but if you are writing application code, we wouldn't seriously consider this as an approach to "writing TypeScript", it's probably worth it to just learn the syntax of TypeScript.
+- You may hear that you can "write TypeScript" with jsdoc comments, and while that is <Resource url='https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html'>technically true</Resource>, we find that writing *application* code that way can be difficult in a way that simply learning TypeScript is not. Maintaining a library is a different story - but if you are writing application code, we wouldn't seriously consider this as an approach to "writing TypeScript" - in other words, we'd recommend to just learn the syntax of TypeScript.
+- If you are interested in this approach, read <Resource url='https://alexharri.com/blog/jsdoc-as-an-alternative-typescript-syntax'>JSDoc as an alternative TypeScript syntax</Resource> by Alex Harri
 </Expand>

src/pages/styling.mdx

@@ -81,9 +81,9 @@ If your app is small enough, it may be simpler to reach for a headless solution
 - <Resource url='https://framework7.io/'>Framework7</Resource>
 - <Resource url='https://ionicframework.com/docs/'>Ionic</Resource>
 
-
-
-### Misc
+## Misc / SVG Icons
 
 - <Resource url='https://www.joshwcomeau.com/react/demystifying-styled-components/'>Demystifying Styled Components - Josh Comeau</Resource>
 - <Resource url='https://ui.shadcn.com/docs'>shadcn/ui</Resource> - Radix + Tailwind components to copy/paste into your project
+- <Resource url='https://lucide.dev/'>Lucide</Resource>
+- <Resource url='https://heroicons.com/'>Heroicons</Resource>