Javascript

Exploring tRPC with Server-first UI Frameworks

Apr 17, 2023

6 min read

My curiosity

If you’re a front-end engineer you’re likely to see RPC (Remote Procedure Call) popping up more and more, if you haven’t already. You’ll probably hear people talking about tRPC, create-t3-stack, Telefunc, or other RPC-related tools and libraries. You might also hear the term “front-end back-end” thrown around, and see people talking about newer “meta-frameworks” like Solid Start, Remix, or Next13. I’ve been noticing it and can’t help but wonder if they are related, or fit together in some way. It’s the reason that I wanted to write this post. So let’s dig in and try to figure out what’s what!

The players

RPC and tRPC

For the sake of this post, I’m going to use tRPC as the guinea pig since it is currently the most popular RPC implementation that I’m aware of. Just like almost everything else in computer science, RPC has been around since the dawn of time.

The basic idea is that a client can call remote functions over a network. That concept sounds pretty simple and easy to grok, but we’ll dive into some of the mechanics shortly. Since TypeScript is able to run on both the client and server, tRPC provides both client and server libraries, and leverages the RPC concept to provide type-safe function calls over the client-server network boundary. Seems pretty powerful and just scanning the docs, it looks like a pretty fantastic developer experience.

The “front-end back-end” and server-first web frameworks

There is a clear trend heading back toward server-first web frameworks. Another practice that has been around since the dawn of the web. I will use Remix as my guinea pig here since they seem to have been sharing the good news the loudest. The core idea here is that we are trending away from SPAs and render-as-you-fetch patterns that require heavy client-side JavaScript bundles, and introduce loading spinner waterfalls into UIs.

Remix includes server-side loader/action functions in their framework that are tied to particular routes or pages. They are functions that run on the server that you can use to fetch data from an API or database, before or while sending the page to the user’s browser.

This is where the term “front-end back-end” comes from. These data loaders feed your front-end and act in a similar way to GraphQL resolvers. It’s a place on the server to offload all of your data-fetching and parsing for a web page. There are a lot of new frameworks popping up right now that lean into this pattern: Solid Start, SvelteKit, NextJS 13, Rakkas, and coming soon, TanStack Start.

Comparing the patterns

On the surface, RPC and data loaders seem very similar. They are essentially just functions that can be invoked over the network, most common with HTTP requests. They can both live in the same codebase, and have mechanisms for inferring types from the server-client boundary. Data loaders use more REST or page-bound HTTP requests, and tRPC follows the RPC specification. They both support CRUD operations through their own respective mechanisms.

The main difference that I see is in the ergonomics of the two patterns. Using the tRPC client, you need to explicitly make a call to your procedure from somewhere in your client or server application. With the data-loaders pattern, your function gets called as part of the request for a particular page or REST endpoint.

The nitty-gritty

Now that we know the players, the question is: can they play on the same team? If you look through the tRPC documentation, it’s clear that it has a very nice client-side story, especially its React and React-Query integrations.

But what about from a server-side data loader?

First, we need to wire up tRPC in our framework of choice. In this case, its Remix.

Hooking up tRPC to a Remix app

Not having a lot of tRPC experience, I found this part to be a little bit confusing. tRPC maintains integrations with NextJS, but it seems that you need to really internalize the docs and all the pieces to know how to properly set it up with any other framework. I found a trpc-remix library that made the process pretty easy, and I read through the source code to get a better idea of exactly what’s needed to accomplish it on your own. The important piece is having an adapter that works for whatever server runtime your framework happens to be using.

Adding a simple query and mutation procedure

For demo purposes, I’m just gonna use a simple tRPC router from their documentation that includes a single query and mutation to our backend database (an array).

export const appRouter = router({
  userById: publicProcedure
    .input((val: unknown) => {
      if (typeof val === 'string') return val;
      throw new Error(`Invalid input: ${typeof val}`);
    })
    .query((req) => {
      const input = req.input;
      const user = userList.find((it) => it.id === input);
      return user;
    }),
  userCreate: publicProcedure.mutation((req) => {
    const id = `${Math.random()}`;
    const user: User = {
      id,
      name: req.input.name,
    };
    userList.push(user);
    return user;
  }),
});

Loading data on the client

We always have the option in a React component to fetch data from our tRPC server on the client. Since we have the React Query integration using trpc-remix, we can query and mutate our data the same way that they do in the Getting Started page of the tRPC docs.

export default function Index() {
  const userQuery = trpc.proxy.userById.useQuery('1');
  return (
    <div>
      <p>{userQuery.data?.name}</p>
    </div>
  );
}

Loading data on the server

Now getting to the fun part. How does it work if we want to load data from our tRPC server from a data loader that is also located on the server?

Well, one option is using the tRPC client to make an HTTP request to our server in the same way that our client would.

export const loader = ({ request }: LoaderArgs) => {
	const user = await trpc.getUser.query('1');
  return json({
		user,
	});
};

This doesn’t feel ideal though. If our tRPC procedures are on the server and our loader is also on the server it would make more sense if we could just invoke it directly. Luckily this is possible and tRPC has a documentation page about the topic.

trpc-remix has a trpcLoader utility that returns an instance of our tRPC router that we can make server calls against. So this actually ends up being a pretty decent experience. We can make a direct call to our getUser procedure from our server loader.

type Loader = typeof loader;

export const loader = async (args: LoaderArgs) => {
  const trpcServer = trpcLoader(args)
  const user = await trpcServer.userById('1')
  return json({
    user
  });
};

We can now update our page component to use Remix’s built-in useLoader hook.

export default function Index() {
  const { user } = useLoader<Loader>()
  return (
    <div>
      <p>{user?.name}</p>
    </div>
  );
}

Mutations from action handlers

We could use trpcLoader to invoke our mutation procedures directly from action handlers as well. A form submission is a good example use case.

import { createPost } from "~/models/post.server"

export const action = async ({ request }: ActionArgs) => {
  const trpcServer = trpcLoader(args)
  const formData = await request.formData();

  const name = formData.get("name");
  const user = await trpcServer.userCreate({ name: 'Frodo' });

  return json({ user });
};

Mutations from the client

Mutations generally spawn from user interaction on the client, so unless you are submitting a form the old-fashioned way, your mutation is happening over the wire. For this purpose, we can use our tRPC client like you would in any other tRPC based application.

export default function Index() {
  const { user } = useLoader<Loader>()
  const userCreator = trpc.proxy.userCreate.useMutation();
  return (
    <div>
      <p>{user?.name}</p>

      <button onClick={() => userCreator.mutate({ name: 'Frodo' })}>
        Create Frodo
      </button>
    </div>
  );
}

Things get a little bit trickier when we start talking about mutations from the client when we are using loaders to fetch our component data on the server like we are doing here.

If we were using tRPC exclusively on the client, we could tell react-query to invalidate the cache for any queries that our mutation might have affected. Since we are loading data on the server in Remix, we need to reach for tools in our framework to run our loaders again from the client.

import { useRevalidator } from "react-router-dom";

export default function Index() {
	let revalidator = useRevalidator();
  const { user } = useLoader<Loader>()
  const userCreator = trpc.proxy.userCreate.useMutation();
	const handleClick = () => {
		userCreator.mutate({ name: 'Frodo' }, {
			onSuccess: revalidator.revalidate
		})
	}
  return (
    <div>
      <p>{user?.name}</p>

      <button onClick={handleClick}>
        Create Frodo
      </button>
    </div>
  );
}

In this example, we use useRevalidator from react-router to re-fetch our loader data. This way, once our mutation completes successfully, {user?.name} will properly reflect the updated value.

Epilogue

It feels like tRPC is more equipped as a tool for building APIs to power the SPA and client-heavy applications. The integration with a full-stack framework didn’t feel very simple and straightforward to me. That being said, once you have correctly integrated tRPC in your application, its API does support invoking your server procedures directly without having to make an HTTP request. If you enjoy the ergonomics of tRPC for building your application API, nothing is stopping you from using it with your full-stack TypeScript framework of choice. It has the added bonus of having an amazing client library for when you want to fetch data, or handle a mutation exclusively on the server.

I think tRPC is another fantastic option for building APIs for your TypeScript applications in a world dominated by REST and GraphQL APIs. I’m happy for the opportunity to explore, and learn that it is still a completely viable choice outside of SPA TypeScript apps. There is a ton of innovation happening in this area right now with new frameworks and RPC libraries. Some of them will integrate with one another. React is planning on building RPC right into the framework to support mutations with server components. I’m excited to see how it all pans out, and hope for an amazing combination of user and developer experience.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Dane Grant

JavaScript developer building things on web, native, and server environments. Free time filled with reading, cooking, dog, sports, comedy, and music.

@danecando @danecando

Understanding Vue's Reactive Data

Introduction Web development has always been about creating dynamic experiences. One of the biggest challenges developers face is managing how data changes over time and reflecting these changes in the UI promptly and accurately. This is where Vue.js, one of the most popular JavaScript frameworks, excels with its powerful reactive data system. In this article, we dig into the heart of Vue's reactivity system. We unravel how it perfectly syncs your application UI with the underlying data state, allowing for a seamless user experience. Whether new to Vue or looking to deepen your understanding, this guide will provide a clear and concise overview of Vue's reactivity, empowering you to build more efficient and responsive Vue 3 applications. So, let’s kick off and embark on this journey to decode Vue's reactive data system. What is Vue's Reactive Data? What does it mean for data to be ”'reactive”? In essence, when data is reactive, it means that every time the data changes, all parts of the UI that rely on this data automatically update to reflect these changes. This ensures that the user is always looking at the most current state of the application. At its core, Vue's Reactive Data is like a superpower for your application data. Think of it like a mirror - whatever changes you make in your data, the user interface (UI) reflects these changes instantly, like a mirror reflecting your image. This automatic update feature is what we refer to as “reactivity”. To visualize this concept, let's use an example of a simple Vue application displaying a message on the screen: ` In this application, 'message' is a piece of data that says 'Hello Vue!'. Let's say you change this message to 'Goodbye Vue!' later in your code, like when a button is clicked. ` With Vue's reactivity, when you change your data, the UI automatically updates to 'Goodbye Vue!' instead of 'Hello Vue!'. You don't have to write extra code to make this update happen - Vue's Reactive Data system takes care of it. How does it work? Let's keep the mirror example going. Vue's Reactive Data is the mirror that reflects your data changes in the UI. But how does this mirror know when and what to reflect? That's where Vue's underlying mechanism comes into play. Vue has a behind-the-scenes mechanism that helps it stay alerted to any changes in your data. When you create a reactive data object, Vue doesn't just leave it as it is. Instead, it sends this data object through a transformation process and wraps it up in a Proxy. Proxy objects are powerful and can detect when a property is changed, updated, or deleted. Let's use our previous example: ` Consider our “message” data as a book in a library. Vue places this book (our data) within a special book cover (the Proxy). This book cover is unique - it's embedded with a tracking device that notifies Vue every time someone reads the book (accesses the data) or annotates a page (changes the data). In our example, the reactive function creates a Proxy object that wraps around our state object. When you change the 'message': ` The Proxy notices this (like a built-in alarm going off) and alerts Vue that something has changed. Vue then updates the UI to reflect this change. Let’s look deeper into what Vue is doing for us and how it transforms our object into a Proxy object. You don't have to worry about creating or managing the Proxy; Vue handles everything. ` In the example above, we encapsulate our object, in this case, “state”, converting it into a Proxy object. Note that within the second argument of the Proxy, we have two methods: a getter and a setter. The getter method is straightforward: it merely returns the value, which in this instance is “state.message” equating to 'Hello Vue!' Meanwhile, the setter method comes into play when a new value is assigned, as in the case of “state.message = ‘Hey young padawan!’”. Here, “value” becomes our new 'Hey young padawan!', prompting the property to update. This action, in turn, triggers the reactivity system, which subsequently updates the DOM. Venturing Further into the Depths If you have been paying attention to our examples above, you might have noticed that inside the Proxy method, we call the functions track and trigger to run our reactivity. Let’s try to understand a bit more about them. You see, Vue 3 reactivity data is more about Proxy objects. Let’s create a new example: ` In this example, when you click on the button, the message's value changes. This change triggers the effect function to run, as it's actively listening for any changes in its dependencies. How does the effect property know when to be called? Vue 3 has three main functions to run our reactivity: effect, track, and trigger. The effect function is like our supervisor. It steps in and takes action when our data changes – similar to our effect method, we will dive in more later. Next, we have the track function. It notes down all the important data we need to keep an eye on. In our case, this data would be state.message. Lastly, we've got the trigger function. This one is like our alarm bell. It alerts the effect function whenever our important data (the stuff track is keeping an eye on) changes. In this way, trigger, track, and effect work together to keep our Vue application reacting smoothly to changes in data. Let’s go back to them: ` Tracking (Dependency Collection) Tracking is the process of registering dependencies between reactive objects and the effects that depend on them. When a reactive property is read, it's "tracked" as a dependency of the current running effect. When we execute track(), we essentially store our effects in a Set object. But what exactly is an "effect"? If we revisit our previous example, we see that the effect method must be run whenever any property changes. This action — running the effect method in response to property changes — is what we refer to as an "Effect"! (computed property, watcher, etc.) > Note: We'll outline a basic, high-level overview of what might happen under the hood. Please note that the actual implementation is more complex and optimized, but this should give you an idea of how it works. Let’s see how it works! In our example, we have the following reactive object: ` We need a way to reference the reactive object with its effects. For that, we use a WeakMap. Which type is going to look something like this: ` We are using a WeakMap to set our object state as the target (or key). In the Vue code, they call this object targetMap. Within this targetMap object, our value is an object named depMap of Map type. Here, the keys represent our properties (in our case, that would be message and showSword), and the values correspond to their effects – remember, they are stored in a Set that in Vue 3 we refer to as dep. Huh… It might seem a bit complex, right? Let's make it more straightforward with a visual example: With the above explained, let’s see what this Track method kind of looks like and how it uses this targetMap. This method essentially is doing something like this: ` At this point, you have to be wondering, how does Vue 3 know what activeEffect should run? Vue 3 keeps track of the currently running effect by using a global variable. When an effect is executed, Vue temporarily stores a reference to it in this global variable, allowing the track function to access the currently running effect and associate it with the accessed reactive property. This global variable is called inside Vue as activeEffect. Vue 3 knows which effect is assigned to this global variable by wrapping the effects functions in a method that invokes the effect whenever a dependency changes. And yes, you guessed, that method is our effect method. ` This method behind the scenes is doing something similar to this: ` The handling of activeEffect within Vue's reactivity system is a dance of careful timing, scoping, and context preservation. Let’s go step by step on how this is working all together. When we run our Effect method for the first time, we call the get trap of the Proxy. ` When running the get trap, we have our activeEffect so we can store it as a dependency. ` This coordination ensures that when a reactive property is accessed within an effect, the track function knows which effect is responsible for that access. Trigger Method Our last method makes this Reactive system to be complete. The trigger method looks up the dependencies for the given target and key and re-runs all dependent effects. ` Conclusion Diving into Vue 3's reactivity system has been like unlocking a hidden superpower in my web development toolkit, and honestly, I've had a blast learning about it. From the rudimentary elements of reactive data and instantaneous UI updates to the intricate details involving Proxies, track and trigger functions, and effects, Vue 3's reactivity is an impressively robust framework for building dynamic and responsive applications. In our journey through Vue 3's reactivity, we've uncovered how this framework ensures real-time and precise updates to the UI. We've delved into the use of Proxies to intercept and monitor variable changes and dissected the roles of track and trigger functions, along with the 'effect' method, in facilitating seamless UI updates. Along the way, we've also discovered how Vue ingeniously manages data dependencies through sophisticated data structures like WeakMaps and Sets, offering us a glimpse into its efficient approach to change detection and UI rendering. Whether you're just starting with Vue 3 or an experienced developer looking to level up, understanding this reactivity system is a game-changer. It doesn't just streamline the development process; it enables you to create more interactive, scalable, and maintainable applications. I love Vue 3, and mastering its reactivity system has been enlightening and fun. Thanks for reading, and as always, happy coding!...

Nov 22, 2023

7 mins

VueJavaScriptTypeScriptWeb Development

End-to-end type-safety with JSON Schema

End-to-end type-safety with JSON Schema I recently wrote an introduction to JSON Schema post. If you’re unfamiliar with it, check out the post, but TLDR: It’s a schema specification that can be used to define the input and output data for your JSON API. In my post, I highlight many fantastic benefits you can reap from defining schemas for your JSON API. One of the more interesting things you can achieve with your schemas is end-to-end type safety from your backend API to your client application(s). In this post, we will explore how this can be accomplished slightly deeper. Overview The basic idea of what we want to achieve is: * a JSON API server that validates input and output data using JSON Schema * The JSON Schema definitions that our API uses transformed into TypeScript types With those pieces in place, we can achieve type safety on our API server and the consuming client application. The server side is pretty straightforward if you’re using a server like Fastify with already enabled JSON Schema support. This post will focus on the concepts more than the actual implementation details though. Here’s a simple diagram illustrating the high-level concept: We can share the schema and type declaration between the client and server. In that case, we can make a request to an endpoint where we know its type and schema, and assuming the server validates the data against the schema before sending it back to the client, our client can be confident about the type of the response data. Marrying JSON Schema and TypeScript There are a couple of different ways to accomplish this: * Generating types from schema definitions using code generation tools * Creating TypeBox definitions that can infer TypeScript types and be compiled to JSON Schema I recommend considering both and figuring out which would better fit your application and workflows. Like anything else, each has its own set of trade-offs. In my experience, I’ve found TypeBox to be the most compelling if you want to go deep with this pattern. Code generation A couple of different packages are available for generating TS types from JSON Schema definitions. * https://github.com/bcherny/json-schema-to-typescript * https://github.com/vega/ts-json-schema-generator They are CLI tools that you can provide a glob path to where your schema files are located and will generate TS declaration files to a specified output path. You can set up an npm hook or a similar type of script that will generate types for your development environment. TypeBox TypeBox is a JSON Schema type builder. With this approach, instead of json files, we define schemas in code using the TypeBox API. The TypeBox definitions infer to TypeScript types directly, which eliminates the code generation step described above. Here’s a simple example from the documentation of a JSON Schema definition declared with TypeBox: ` This can then be inferred as a TypeScript type: ` Aside from schemas and types, TypeBox can do a lot more to help us on our type-safety journey. We will explore it a bit more in upcoming sections. Sharing schemas between client and server applications Sharing our JSON Schema between our server and client app is the main requirement for end-to-end type-safety. There are a couple of different ways to accomplish this, but the simplest would be to set up our codebase as a monorepo that contains both the server and client app. Some popular options for TypeScript monorepos are: PNPM, Turborepo, and NX. If a monorepo is not an option, you can publish your schema and types as a package that can be installed in both projects. However, this setup would require a lot more maintenance work. Ultimately, as long as you can import your schemas and types from the client and server app, you are in good shape. Server-to-client validation and type-safety For the sake of simplicity, let's focus on data flowing from the server to the client for now. Generally speaking, the concepts also apply in reverse, as long as your JSON API server validates your inputs and outputs. We’ll look at the most basic version of having strongly typed data on the client from a request to our server. Type-safe client requests In our server application, if we validate the /users endpoint with a shared schema - on the client side, when we make the request to the endpoint, we know that the response data is validated using the user schema. As long as we are confident of this fact, we can use the generated type from that schema as the return type on our client fetch call. Here’s some pseudocode: ` Our server endpoint would look something like this: ` You could get creative and build out a map that defines all of your endpoints, their metadata, and schemas, and use the map to define your server endpoints and create an API client. Transforming data over the wire Everything looks stellar, but we can still take our efforts a bit further. To this point, we are still limited to serialized JSON data. If we have a created_at field (number or ISO string) tied to our user, and we want it to be a Date object when we get a hold of it on the client side - additional work and consideration are required. There are some different strategies out there for deserializing JSON data. The great thing about having shared schemas between our client and server is that we can encode our type information in the schema without sending additional metadata from our server to the client. Using format to declare type data In my initial JSON Schema blog post, I touched on the format field of the specification. In our schema, if the actual type of our date is a string in ISO8601 format, we can declare our format to be "date-time". We can use this information on the client to transform the field into a proper Date object. ` Transforming serialized JSON Data This can be a little bit tricky; again, there are many ways to accomplish it. To demonstrate the concept, we’ll use TypeBox to define our schemas as discussed above. TypeBox provides a Transform type that you can use to declare, encode, and decode methods for your schema definition. ` It even provides helpers to statically generate the decoded and encoded types for your schema ` If you declare your decode and encode functions for your schemas, you can then use the TypeBox API to handle decoding the serialized values returned from your JSON API. Here’s what the concept looks like in practice fetching a user from our API: ` Nice. You could use a validation library like Zod to achieve a similar result but here we aren’t actually doing any validation on our client side. That happened on the server. We just know the types based on the schema since both ends share them. On the client, we are just transforming our serialized JSON into what we want it to be in our client application. Summary There are a lot of pieces in play to accomplish end-to-end type safety. With the help of JSON Schema and TypeBox though, it feels like light work for a semi-roll-your-own type of solution. Another great thing about it is that it’s flexible and based on pretty core concepts like a JSON API paired with a TypeScript-based client application. The number of benefits that you can reap from defining JSON Schemas for your APIs is really great. If you’re like me and wanna keep it simple by avoiding GraphQL or other similar tools, this is a great approach....

Apr 17, 2024

6 mins

JSONTypeScript

JSR - The cross-platform package manager for ESM

JSR - The cross-platform package manager for ESM Move over NPM, there’s a new package manager in town. JSR is a new open-source package registry for JavaScript and TypeScript. This particular release has caught my attention, and I’m excited to explore if and where JSR fits into our overflowing ecosystem. Setting the stage The JSR website has a page called Why JSR? I want to explore the _why_ a little bit further. I think that the _why_ points to JSR potentially being the future of the JavaScript ecosystem. NPM and JavaScript modules If you’ve found yourself confused about publishing and consuming packages and modules in the modern ESM era, you’re not alone. When NodeJS was created, there was no standard for JS modules. Node introduced CommonJS modules, and NPM provided a way to publish and consume these modules in our applications. It’s been years now since ES Modules became a standard and we are still in a weird module purgatory with no clear end in sight. JSR represents a fresh start, free from the baggage of the Node and NPM ecosystems. JavaScript runtimes and interoperability New JavaScript runtimes are popping up every year. WinterCG (_Web-interoperable Runtimes Community Group)_ was started to improve interoperability for the various runtimes with some standard APIs. Node has made steps towards this goal, but it might never get all the way there and NPM is coupled pretty tightly to that ecosystem. JSR supports several runtimes (depending on the package). This is a huge opportunity for it to become the package manager for the ecosystem at large. See cross-runtime support section for more details. NPM Compatibility JSR doesn’t end up being a complete departure from NPM since it includes an NPM compatibility layer. The docs highlight some limitations and provide deeper technical details on how this piece works. The simple overview is that you can install and use packages from JSR to a Node/NPM based project. The packages will get added to your package.json and node_modules directory. About the same as any package installed from NPM. JSR Overview At a high level, JSR is very similar to NPM. You can search for packages on the website. You can publish packages to their registry, and you can download packages from it as well. We touched on the two major features that set it apart from NPM: It only supports ESModules, and it has cross-runtime support. In the rest of the article we’ll explore the essentials (package management) and also some other really great features that feel like are bringing the JS package management ecosystem up to speed with our modern workflows. Native TypeScript I have to say I’m not surprised by this feature, considering JSR was developed by the same people behind Deno (a runtime that supports TS natively). It’s a great feature. If you haven’t figured it out yet TypeScript is a big deal and doesn’t seem to be fading away anytime soon. So what exactly does TS support look like in a package manager, though? If your runtime supports TypeScript natively (like Deno) - it can consume the TS files in your package directly. For environments that don’t, it will automatically compile your code to JavaScript and package it with type declaration files (.d.ts). Pretty, stinking, cool. The docs include a page called “about slow types”. It is probably worth a read on its own ,but the TLDR is that JSR will analyze your TS code and penalize you in certain ways if you have some type code that it considers to be slow. On the page, it outlines exactly what these penalties are, as well as what it considers slow types to be. Slow types will also come into play when we get into package scoring later in the article. Packages The docs have a page dedicated to packages. It covers some important stuff like deleting packages, versioning, documentation, and publishing. We’ll touch on some of it with an emphasis on the things that are done differently or better than with NPM. jsr.json file jsr.json is a configuration file that specifies a name, version, and exports of a package. It doesn’t include a list of dependencies like you would have in a package.json file. This is a configuration file for a package to be published to JSR. JSR dependencies are defined in an import map file or a package.json file, depending on the runtime. Adding packages to a project Adding packages to your project will vary depending on your target runtime. Here’s an example of installing it for Deno and NPM using various package managers. For Deno, an import map entry is created. For NPM, it gets installed as an NPM package using the JSR NPM compatibility layer. ` If the runtime has native JSR support, you don’t need to explicitly install packages. You can important them using the jsr: scheme. ` As you can see semantic versioning is supported and works similarly to NPM. Publishing packages If you want to publish a package to JSR, there are many important rules you need to be aware of. I recommend reading “Publishing packages” before moving forward with this. The main things to note are: ESModules only, npm packages are supported, JSR packages are supported, and node APIs are supported. So there aren’t many constraints. You just need to understand how exactly to do these things. IE: how do I use NPM dependencies, how do the imports work, etc? Once you’ve got all that down, you will be ready to publish your first package to JSR 😃 Documentation JSR emphasizes quality package documentation. It’s one of the factors in their package scoring algorithm, which we will discuss shortly. The important parts of a package’s documentation include: * a README.md file * symbol documentation - functions, interfaces, classes, etc * module documentation - docs for each exported module in a package The symbol and module documentation are written using JSDoc. The JSR website generates some nice documentation based on these 3 pieces on your package page. This means you can understand a package's entire public API without ever leaving jsr.io. Browser support The cross-runtime support is amazing, but I was curious where the original JavaScript runtime fit (the browser). According to the documentation: “You can use JSR with any tool that supports ES modules, and either has native support for JSR or supports npm packages using node_modules.” Since modern web browsers support ES modules, I will count this as JSR support. From what I can tell, though, there is one caveat. To include a module on a web page, we need a URL to download it from. Can we publish our package to JSR and use it to load a module via a script tag? According to the JSR usage policy, no. The “Unacceptable use” section states: “It is not acceptable to use JSR as a CDN for serving assets directly to web applications in a browser, except for development purposes.” So, it seems that this is a no-go for now. We will probably need to wait a bit for CDN services like jsdelivr to pull packages from the JSR registry, similar to what they do with NPM currently. Other notable features We’ve covered the most important bits about package management, TS support, NPM compatibility, etc. But there are still a few unique features that add an extra bit of sparkle to JSR. Scoring We mentioned earlier that documentation plays a part in a scoring algorithm. JSR analyzes all of the packages published to its registry and assigns them a score based on certain criteria: documentation, best practices, discoverability, and compatibility. This score is shown with every package listed on the website. You can also add a shiny badge to your README if you’re particularly proud of something. It’s still early on, so it’s likely this will evolve as time goes on. It’s an interesting gimmick, at the very least! Summary I am excited to have a new cross-platform compatible package manager that only supports ESM. As useful as NPM has been all these years, it carries a lot of baggage from “the olden days”. JSR’s native TypeScript support and reliance on modern standards is a breath of fresh air. It feels like I can publish a simple package without much ceremony. I’m excited to release my first package to JSR soon :)...

Apr 12, 2024

6 mins

JSRJavaScript

The Future of JavaScript Package Handling and Open Source with Darcy Clarke

Darcy Clarke shares his thoughts on package distribution, open-source sustainability, and vlt.sh, a new package manager which he has been building with npm Creator Isaac Schlueter and Node TSC member Ruy Adorno. This conversation with Tracy Lee, Adam Rackis, and Ben Lesh sheds light on the challenges faced by developers, the imperative for enhanced tools, and the significance of collaboration and innovation within the community. Darcy Clarke pressed the need for simplified package authoring, advocating for improved tools within the JavaScript ecosystem to streamline processes and boost developer productivity. He underscored the hurdles encountered by package authors and the potential for innovation in this domain. As JavaScript continues, the need for efficient package distribution and management tools becomes increasingly paramount. Download this episode here....

Apr 12, 2024

1 min

Engineering Leadership

Exploring tRPC with Server-first UI Frameworks

My curiosity

The players

RPC and tRPC

The “front-end back-end” and server-first web frameworks

Comparing the patterns

The nitty-gritty

Hooking up tRPC to a Remix app

Adding a simple query and mutation procedure

Loading data on the client

Loading data on the server

Mutations from action handlers

Mutations from the client

Epilogue

Dane Grant

You might also like

Understanding Vue's Reactive Data

End-to-end type-safety with JSON Schema

JSR - The cross-platform package manager for ESM

The Future of JavaScript Package Handling and Open Source with Darcy Clarke

You might also like

Understanding Vue's Reactive Data

End-to-end type-safety with JSON Schema

JSR - The cross-platform package manager for ESM

The Future of JavaScript Package Handling and Open Source with Darcy Clarke