Don’t overload AI with instructions/ context you are still the code owner, you must understand why AI made the changes it did otherwise you cannot spot errors/ over engineering Strive for consistent and sensible patterns that AI can find / reuse use unambiguous language when speaking with the agent and in terms of context do… Continue reading Tips for coding with AI
Author: Darryl
Anti-pattern – are You overusing useEffect?
Consider this very basic example. The problem here is – we relying on React specific patterns for something that could easily be handled natively. Specifically – there is absolutely no need to utilize component state + post render effect when we can simply call the logic in the native event handler passed to button. Let’s… Continue reading Anti-pattern – are You overusing useEffect?
TypeScript best practice guide
1. Introduction TypeScript is not real when compared to the type systems found in languages like C# / Java for example, it has absolutely no power at runtime because it does not exist in the native code we send to the browser, so we must not write development code that skews logical inference as that… Continue reading TypeScript best practice guide
TypeScript: any vs unknown
Ideally we should never use any, but let’s say we are migrating a legacy project to TypeScript and some degree of pragmatism is in order. Let’s consider this block of code: to get the ball rolling with TypeScript someone probably added an any type here and it seems fairly safe as we never do anything… Continue reading TypeScript: any vs unknown
errors: dev time vs compile time vs runtime
When writing code one of our goals should always be to catch errors as early as possible. If our tools / code exist in a way that means we don’t catch all or most errors until runtime…then we have serious flaws in our approach. Take TypeScript for example. If we actually use this tool right… Continue reading errors: dev time vs compile time vs runtime
TypeScript – don’t misuse casting
When feeling like you want to solve a type error with forceful casting, consider using one of TypeScript’s utility types instead. And please never use this pattern – object as unknown as SomeType Casting like this takes away TypeScripts power because you are now telling it what to believe rather than the tooling basing that… Continue reading TypeScript – don’t misuse casting
React 19 beta and (later) React Compiler
Checkout the React 19 beta: https://react.dev/blog/2024/04/25/react-19 These changes seem more quality of life vs some of the lower level performance type changes we saw in React 18. React Compiler is the more exciting prospect here, current claims are that it will cut out the need for a lot of the efficiency fluff code we have… Continue reading React 19 beta and (later) React Compiler
react – don’t go crazy with memoization
check out this great article outlining how it can be very easy to misuse things like useCallback and useMemo dynamics in react projects https://kentcdodds.com/blog/usememo-and-usecallback And don’t forget – once React compiler lands we might be able to get rid of even more of these, then again don’t be too hasty….you may need to check a… Continue reading react – don’t go crazy with memoization
Check out Vite
I recently used Vite for a home project and I found it much better “out of the box” than webpack. I also used Vitest instead of Jest as my test runner, and it worked perfectly. https://vitejs.dev
Keep your FE dumb!
Try to keep your client as dumb as possible, to achieve this you should avoid the following: In many cases your service layer can take the heavy lift away from the FE which takes away complexity/ risk and avoids duplicating/ mutating business logic + domain sources of truth.