Imagine a world where coding for the web was akin to painting with charcoal on rough cave walls—primitive, cumbersome, and lacking finesse. That was the early 2000s for JavaScript developers. Fast forward to today, the tools and languages have evolved drastically, making modern web development a refined art. Among these developments, two languages stand out in their influence and capability: …
Software development is an ever-evolving space where languages, tools, and best practices can rapidly change based on the market. Yet there is always a race to do things faster and better than before.
Today, I will be introducing you to Turborepo, a tool that helps manage JavaScript and TypeScript monorepos by leveraging build techniques to avoid duplicate work and maximize multitasking at scale. But first, there may be a couple of questions you’re asking yourself. What is a monorepo, and why use Turborepo?
Over the years, we’ve seen many approaches to HTTP API design. While REST APIs are still very popular throughout the industry, they offer no inherent guarantees that the client’s assumptions about the response structures will be valid.
GraphQL fills this gap to an extent by allowing client-side code greater control over the resulting structures but at the cost of added complexity. RPC (remote procedure call) frameworks attempt a different solution by sharing generated type definitions between the client and server implementations. What if there was a way to achieve the type safety of RPC by simply inferring the type definitions from the server’s code?
Enter tRPC. Since JavaScript (and specifically TypeScript) can already span across client and server implementations, tRPC allows a client to directly consume structures defined by the server’s exposed procedures. Essentially, you import your dependencies from the server to access these procedures, their return types are inferred and checked at build time, and your client code can confidently consume the returned data.
In this post, we’ll look at how it achieves these goals and what limitations it places on your project stack.
For this blog, I’m going to continue using the example project I’ve used for the last several blogs, Whirlpool. You can find my last post on the Keyhole Dev Blog – Updating Microservices with Netty, Kafka, and React: Whirlpool revisited. Feel free to go back and read about microservices, Netty, Kafka, and React, or just start here with me and continue on the journey. Either way, I’m glad you’re here.
The focus of this blog will be creating Redux’s InitialState using TypeScript. It tends to be tricky to get it to stop complaining about types, so this should be helpful. Personally, I’ve encountered this issue several times across multiple projects, so I think it is worth talking about.
No matter how much you love JavaScript, as with all languages, there are certain aspects of it that are bothersome and frustrating. The lack of strict typing of variables/objects and the mysterious reference errors that don’t present themselves until run-time are among the most common complaints about JavaScript. Luckily, TypeScript offers a solution, especially for React-based applications.
TypeScript alleviates these headaches for vanilla Javascript. When integrated with a JavaScript framework like React, web application development becomes much more consistent with a standard object-orientated language.
In this blog post, I will be giving you a high-level breakdown of what TypeScript is and how to use it with either a new or existing React application.
