From dca67d807514820aaac4a4845a81f90ad7f5a752 Mon Sep 17 00:00:00 2001 From: Eric Diviney Date: Tue, 30 Jul 2024 22:20:55 -0500 Subject: [PATCH] Updates I've been wanting to push for a while, finally sat down and made them from my bookmarks. --- src/components/pages/State.jsx | 2 +- src/pages/automated-testing.mdx | 3 ++- src/pages/frameworks/react-native.mdx | 9 +++++---- src/pages/fundamentals.mdx | 1 + src/pages/project-standards.mdx | 3 ++- src/pages/styling.mdx | 6 +++--- 6 files changed, 14 insertions(+), 10 deletions(-) diff --git a/src/components/pages/State.jsx b/src/components/pages/State.jsx index 72c094b..df3c37d 100644 --- a/src/components/pages/State.jsx +++ b/src/components/pages/State.jsx @@ -102,7 +102,7 @@ export function GreenfieldContent() { For extremely complex state, consider state machines like{' '} - xState + xState (or the simpler @xState/xStore) diff --git a/src/pages/automated-testing.mdx b/src/pages/automated-testing.mdx index 655db79..0a9d5ca 100644 --- a/src/pages/automated-testing.mdx +++ b/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: React Hooks Testing Library - 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: diff --git a/src/pages/frameworks/react-native.mdx b/src/pages/frameworks/react-native.mdx index c2a096c..070d9dd 100644 --- a/src/pages/frameworks/react-native.mdx +++ b/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 Project Standards 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 here, along with the entire series 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. +- React Native Tutorial +- From Web to Native with React +- reddit.com/r/reactnative - -## 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 here. diff --git a/src/pages/fundamentals.mdx b/src/pages/fundamentals.mdx index 3103333..803164a 100644 --- a/src/pages/fundamentals.mdx +++ b/src/pages/fundamentals.mdx @@ -37,6 +37,7 @@ The class of bugs you're getting rid of are all those pesky (…cannot read… ' - Why TypeScript? - Beginner's TypeScript - A (free) interactive video course by Matt Pocock - React with TypeScript - Another free video course by Matt Pocock +- Total TypeScript Essentials - No BS TS - A (free) video course by Jack Herrington - Learn TypeScript - Full Tutorial - TypeScript errors - How to fix your confusing TypeScript errors diff --git a/src/pages/project-standards.mdx b/src/pages/project-standards.mdx index d27d0ce..685bc4c 100644 --- a/src/pages/project-standards.mdx +++ b/src/pages/project-standards.mdx @@ -283,5 +283,6 @@ It also prevents an entire class of bugs from arising, and gives IDE more capabi Commenting systems like JSDoc - 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 generated 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 technically true, 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 technically true, 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 JSDoc as an alternative TypeScript syntax by Alex Harri diff --git a/src/pages/styling.mdx b/src/pages/styling.mdx index 270c539..63f70b5 100644 --- a/src/pages/styling.mdx +++ b/src/pages/styling.mdx @@ -81,9 +81,9 @@ If your app is small enough, it may be simpler to reach for a headless solution - Framework7 - Ionic - - -### Misc +## Misc / SVG Icons - Demystifying Styled Components - Josh Comeau - shadcn/ui - Radix + Tailwind components to copy/paste into your project +- Lucide +- Heroicons