Paul Grenyer

Async functions are a powerful feature in JavaScript and TypeScript, offering a cleaner, more readable alternative to working directly with Promises. However, it’s easy to overuse them or add unnecessary layers of complexity.  By understanding when and how to use async and await effectively, you can write more concise, efficient, and maintainable code. Let’s explore a common scenario where async and await may be overapplied, and how simplifying the function structure can improve code readability and maintainability without sacrificing intent. Take a look at this function which wraps an async function which deletes an entity form a database: const deleteEntity = async (id: number) => {     return await db.entity.delete({ id }); } You would also await deleteEntity when calling it, resulting in two promises, unnecessarily verbose code and less efficient execution.. Instead of awaiting the promise created in deleteEntity , it can just be returned: const deleteEntity ...

axios-http-builder is a n Axios i nstance builder for use on client or server side with common features pre-configured: - Timeout - Cancellation By default, Axios does not configure a timeout or a cancellation timeout. However, axios-http-builder sets both to 2 seconds by default, which remains configurable. axios-http-builder also includes an optional exception handler. Install npm i -save axios-http-builder   Usage To use the default configuration, instantiate the Axios instance with buildHttpClient and then use as normal: import { buildHttpClient } from 'axios-http-builder'; const httpClient = buildHttpClient(); await httpClient.get('https://myservice/entity'); buildHttpClient takes a CreateAxiosDefaults object, so you can use any of Axios' options as normal: import { buildHttpClient } from 'axios-http-builder'; const httpClient = buildHttpClient({ baseURL: 'https://myservice' }); await httpClient.get('/entity'); The axios-http-buil...

Something I see a lot, especially in node applications, is duplicate messages logged due to an exception being caught and logged in several places as the stack unwinds. For example with the following (contrived) code: const httpCall = () => {   const url = 'http://example.com';   try {     throw new Error('Something went wrong!');   } catch (error: any) {     log(error.message, { url });     throw error;   } }; The real error is here in httpCall , but some context about the error needs to be logged, so it is caught, logged and rethrown. const callService = () => {   const someContext = 'The service we called';   try {     httpCall();   } catch (error: any) {     log(`Service failed: ${error.message}`, { someContext });     throw error;   } } ; httpCall is called from a service wrapper, which has its own context which needs to be logged, so again the er...

How we use comments in code has come up a couple of times for me this week and when I looked, I realised we hadn't captured anything in the my teams's coding guide lines, so I added something:   Uncle Bob Says : "It is well known that I prefer code that has few comments. I code by the principle that good code does not require many comments. Indeed, I have often suggested that every comment represents a failure to make the code self explanatory. I have advised programmers to consider comments as a last resort." Comments should always be 'why', never 'what' and only when absolutely necessary. If you feel the need to write a 'what' comment, put the code in a well named (read descriptive) function instead.   There will be those of you who will be adamantly attached to your comments, but you don't need them. And at some point, in the past, now or in the future, you or someone else will update your code, making the comment wrong and forget to upd...