Javascript

How to Handle Async Data Fetching Using CreateResource in SolidJS

Feb 27, 2023

5 min read

In this article, you will learn how to handle async data fetching using createResource in SolidJS. The article assumes that you have a basic understanding of SolidJS. If you need a refresher, I recommend looking at the official SolidJS website to get started with SolidJS. You can also visit solidjs.framework.dev/ for a list of SolidJS libraries and resources.

What is createResource?

createResource is a special Signal designed specifically to handle async data fetching.

Signals are the cornerstone of reactivity in SolidJS. They contain values that change over time, but unlike typical values, Signals are also event emitters. When the data kept in the Signal is changed, the Signal emits events in the system so things that depend on the Signal value can be notified.

Signals are similar to “observables'', “streams”, or “subjects” in other reactive programming technologies. For more information on Signals, check out the SolidJS Documentation.

The purpose of createResource is to wrap async values (any value that returns as a promise) in a way that makes them easy to interact with in Solid's execution model. This is useful because it ensures that the async function is non-blocking.

How does createResource work?

For createResource to work, it needs an argument which is a function that returns a promise. It returns a data getter that wraps the value returned from the fetcher function.

Easy right? The resulting Resource Signal (products) also contains reactive loading and error properties that make it easy to control the view based on the current status.

Let’s see how all of these are used in an example.

In this example, we created a fetcher function that makes a call to get a list of products, and this function is passed in as an argument to createResource. createResource returns a Signal which has reactive properties like loading, error, latest, etc. We use the properties to conditionally render JSX based on the current reactive state.

createResources can also take in a source Signal as the first argument and the async fetcher function as the second. The source Signal is provided as the query to the async fetcher function which returns a promise. A change in the source Signal calls an internal fetch method to fetch new data based on the change. If you are familiar with React-query, source Signals are similar to query keys.

Let’s write an example that fetches users’ profiles from GitHub. It takes the username as input and returns the user’s profile details.

Here we are fetching a GitHub user’s info. We have an input field that receives the username and set it as a Signal. The createResource takes the source Signal as the first argument and the async fetcher function as the second argument. An internal fetch method will be called anytime the Signal value changes. So if we enter a different username into the input field, createResource is aware of that change, and fetches new data based on the new Signal value.

Refetch and Mutate

The second value that comes back from createResource contains a mutate method for directly updating the internal Signal, and a refetch method to reload the current query even if the source hasn't changed.

Mutate is useful for "optimistic mutations" like when you want to automatically update a todo list that is fetched from the server when someone clicks the add button.

Refetch is useful when you know the data returned from the server changes constantly and you would like to get the latest information. For example, if you are building an application that needs to show the current price of Bitcoin in US dollars, you will need to refetch the data because the prices fluctuate.

Why is createResources special?

For small examples, createResource can be as simple as just setting a Signal. However, it interacts with the broader Solid framework in different ways:

When your app is server-side rendered, createResource is fetched on the server while effects and Signal setters aren't, so resources work a lot better with solid start.

Any loading resources will put your app in suspense mode which can automatically provide benefits when interacting with the Solid router.

Conclusion

In this article, we saw how to handle async data fetching using createResource. We also explored some use cases, and when and how to use some properties and methods returned by createResource. You can find the live example for this blog post on StackBlitz.

If you would like to learn more about SolidJS, check out solidjs.framework.dev for a list of libraries and resources.

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.

Victor Umeh

Software Engineer. Passionate about web developement with specialty in Reactjs and Nextjs. He also interested in web3 and blockchain development. In his free time he plays soccer.

@Vyktoreumeh @vyktoremario

Why Every Developer Should Try Elm, + Are We Abandoning JavaScript? with Lindsay Wardell

Lindsay Wardell, Senior Software Engineer at NoRedInk joins Rob Ocel by covering many of the functional programming advantages afforded by Elm. By immersing themselves in the intricacies of languages like Elm, developers can harness its functional approach to bolster application resilience and minimize errors. Lindsay draws parallels with TypeScript's emphasis on strong typing, and how it empowers developers to detect and rectify errors early on, fostering the creation of more maintainable codebases. A pivotal theme emerging from Lindsay's discussions is the importance of adaptability in choosing which languages a developer focuses their energy on. As technology continues to evolve, developers must embrace versatility to remain competitive. Lindsay and Rob Ocel talk about the potential shifts in front-end development paradigms, beyond the dominance of component-based frameworks like React. This underscores the necessity of keeping an open mind and exploring emerging technologies to stay at the forefront of the industry's evolution. Moreover, Lindsay and Rob accentuate the significance of tools such as Nuxt for facilitating seamless backend integration within frameworks like Vue.js. These integrations streamline the development process, enabling developers to concentrate on crafting robust and scalable applications. Their conversations serve as a testament to the ongoing evolution of programming tools, marked by a trend towards simplification and enhanced development efficiency. Download this episode....

Apr 3, 2024

1 min

JavaScriptTypeScript

Overview of the New Signal APIs in Angular

Overview of the New Signal APIs in Angular Google's Minko Gechev and Jeremy Elbourn announced many exciting things at NG Conf 2024. Among them is the addition of several new signal-based APIs. They are already in developer preview, so we can play around with them. Let's dig into it, starting with signal-based inputs and the new matching outputs API. Signal Based Inputs Discussions about signal-based inputs have been taking place in the Angular community for some time now, and they are finally here. Until now, you used the @Input() decorator to define inputs. This is what you'd have to write in your component to declare an optional and a required input: ` With the new signal-based inputs, you can write much less boilerplate code. Here is how you can define the same inputs using the new syntax: ` It's not only less boilerplate, but because the values are signals, you can also use them directly in computed signals and effects. That, effectively, means you get to avoid computing combined values in ngOnChanges or using setters for your inputs to be able to compute derived values. In addition, input signals are read-only. The New Output I intentionally avoid calling them signal-based outputs because they are not. They still work the same way as the old outputs. The Angular team has just introduced a new output API that is more consistent with the latest inputs API and allows you to write less boilerplate, similar to the new input API. Here is how you would define an output until now: ` Here is how you can define the same output using the new syntax: ` The thing I like about the new output API is that sometimes it happens to me that I forget to instantiate the EventEmitter because I do this instead: ` You won't forget to instantiate the output with the new syntax because the output function does it for you. Signal Queries I am sure most readers know the @ViewChild, @ViewChildren, @ContentChild, and @ContentChildren decorators very well and have experienced the pain of triggering the infamous ExpressionChangedAfterItHasBeenCheckedError or having the values unavailable when needed. Here is a refresher on how you would use these decorators until now: ` With the new signal queries, similar to the new input API, the values are signals, and you can use them directly in computed signals and effects. You can define the same queries using the new syntax: ` Jeremy Elbourn mentioned that the new signal queries have better type inference and are more consistent with the new input and output APIs. He also showcased a brand new feature not available with the old queries. You can now define a query as required, and the Angular compiler will throw an error if the query has no result, guaranteeing that the value won't be undefined. Here is how you can define a required query: ` Model Inputs Jeremy and Minko announced the last new feature is the model inputs. The name is vague, but the feature is cool—it simplifies the definition of two-way bindings. Until now, to achieve two-way binding, you would have to define an input and an output following a given naming convention. @Input and @Output had to be defined with the same name (followed by "Change" in the case of the output). Then, you could use the template's [()] syntax. ` ` That way, you could keep the value in sync between the parent and the child component. With the new model inputs, you can define a two-way binding with a single line of code. Here is how you can define the same two-way binding using the new syntax: ` The html template stays the same: ` The model function returns a writable signal that can be updated directly. The value will be propagated back to any two-way bindings. Conclusion The new signal-based APIs are a great addition to Angular. They allow you to write less boilerplate code and make your components more reactive. The new APIs are already in developer preview, so you can start playing around with them today. I look forward to seeing how the community will adopt these new features and what other exciting things the Angular team has in store for us, such as zoneless apps by default....

Apr 3, 2024

3 mins

AngularJavaScript

File Based Routing with Expo Router

Introduction If there is one thing most Javascript developers love, it is file-based routing, and with the advent of frameworks like Next.js, this form of routing has become more popular and most preferred when building applications. The React Native community will not be left out, as earlier this year, Expo released the Expo router, which implements the file-based routing convention. Currently, the Expo router is in V2, which is supported by version 49 of the Expo SDK. In this article, we will take a look at the features that the Expo router offers and explore its file-based routing system. What is Expo Router? Expo Router is a file-based router for React Native and web applications. It allows you to manage navigation between screens in your app, allowing users to move seamlessly between different parts of your app's UI, using the same components on multiple platforms (Android, iOS, and web). It brings the best file-system routing concepts from the web to a universal application, allowing your routing to work across every platform. When a file is added to the app directory, the file automatically becomes a route in your navigation. Features of Expo Router - Native: It is built on the React Navigation suite, Expo Router navigation is truly native and platform-optimized by default. - Shareable: Every screen in your app is automatically deep linkable, making any route in your app shareable with links. - Offline-first: Handles all incoming native URLs without a network connection or server. Apps are cached and run offline first, with automatic updates when you publish a new version. - Optimized: Routes are automatically optimized with lazy evaluation in production and deferred bundling in development. - Iteration: Universal Fast Refresh across Android, iOS, and the web, along with artifact memoization in the bundler to keep you moving fast at scale. - Universal: Android, iOS, and web share a unified navigation structure, with the ability to drop down to platform-specific APIs at the route level. - Discoverable: Expo Router enables build-time static rendering on the web and universal linking to native. Meaning your app content can be indexed by search engines. Expo routing conventions Let’s build a simple application to discuss the various routing conventions and explore some features of the Expo router. To get started, all you need to do is run the following command ` This will create a bare-bone expo project with an Expo router. By default, it is not configured to use typescript. To add a typescript to the project, go to the root of the project and run: ` Expo also provides a way to create a minimal project with the Expo Router library already installed. To create a project, run the command: ` For this article, we will stick with the first approach. Route navigation Now let’s create our first page. Create a file called app/index.tsx and add the following code: ` From the above code, we see that the expo router provides a Link component for navigation. This is very familiar to how the web works with anchor tag and the href attribute. The Link component wraps the children in a component by default; this is useful for accessibility but not always desired. You can customize the component by passing the asChild prop, which will forward all props to the first child of the Link component. The child component must support the onPress and onClick props, href and accessibilityRole will also be passed down. Additionally, we can also use the useRouter hook to navigate to a route. This is very useful if navigating from a global store or custom hook. Layout Routes At the moment, any page we create covers the whole screen, and this is not perfect in most native apps. In that case, we can define a layout that will wrap our pages and add a header and footer, or in our case, a native stack component. This follows the same approach as the usual React Native stack, and we can define the different screens based on their file name. Let’s create a root layout app/_layout.tsx file: ` From the above code, we added the native stack component to define the different screens on the app. We also added screenOptions to add some basic header styles This is useful if you want to define the layout style for all routes. You can also change the layout for each screen by adding various style options to the options property in the component. Furthermore, if you create a directory that groups different routes, you can create a layout for those routes. Unmatched Routes From our example above, we do not have a register page, so if we try to click on the link and visit that page, we will get an unmatched error page. Expo router provides a default unmatched route. This is the fallback page when you try to reach a route that does not exist. You can customise this route by creating a file called app/[...unmatched].tsx and exporting any component you want to render instead. Be sure to have a link to ‘/’ so users can navigate back to the home screen. Groups Groups are used to organize sections of the app. When we wrap a directory name in parenthesis (e.g., (profile)), it does so without adding segment to the URL. This is mostly useful when you are developing for the web, and you don’t want the group name to exist as a segment on the URL. Let’s create a group named (tabs). This will contain two tab files: home and account. Create a file name apps/(tabs)/home.tsx and add the following code: ` Create another file called apps/(tabs)/account.ts and add the following code: ` We can now add a layout to the (tabs) group. The layout won’t use a component but will use a component. Create a _layout.tsx file inside the (tabs) directory and add the following code: ` From the above code, we created two tabs for the Home page and the Account page. We added the appropriate icons for those tabs. On the homepage, we added a Logout link. In the Link component, we added a replace attribute because using the Link component is almost the same as calling router.push(). It adds the route on top of the stack. But since this is a Logout link, we need to replace all existing navigation stacks with the route. By default, you should be able to navigate to the tabs screen, but you will notice that it has multiple header sections as seen below: You will notice that there are two header sections. The first header with the title (tabs) is inferred by the Expo router, and it uses the styling from the root layout. The second header was created when we added some options in the component. We can remove any of the headers depending on our app design. To remove the first header, we must add the (tabs) route as a screen to the root layout and set the headerShown to false. So go to the _layout.tsx file on the root of the app directory and add the following code: ` We are setting the headerShown to false because the (tabs) group also has a layout, and each tab on the layout has an option that sets the headerTitle and other header properties. That is the header we would show, as they will change for the different tabs. If we want a static header for both tabs, we can add headerShown: false to all tabs options on the tab layout. Shared routes To match the same URL with different layouts, use groups with overlapping child routes. This pattern is very common in native apps. For example, in the Twitter app, a profile can be viewed in every tab (such as home, search, and profile). However, there is only one URL that is required to access this route. Here is an example of how a shared route is structured: Shared routes can be navigated directly by including the group name in the route. For example, /(search)/victor navigates to /victor in the "search" layout. Kindly note that for web apps, when you directly type/victor on your browser, the Expo router cannot tell which [user].tsx you are trying to reach, so it gets the first route that matches the path from your file tree (In the case above, it is the (home)/[user].tsx). Shared routes are most useful in tab navigations because it is easier to know the group from which the route was visited and keep the tab active. Arrays Instead of defining the same route multiple times with different layouts, we can use the array syntax (,) to duplicate the children of a group. For example, app/(home,profile,search)/[user].tsx creates app/(home)/[user].tsx, app/(profile)/[user].tsx and app/(search)/[user].tsx in memory. To distinguish between the two routes, use a layout's segment prop: ` Dynamic Route Dynamic routes match any unmatched path at a given segment level. For example, if I have a directory named contacts, I can create a dynamic route for each contact app/contacts/[slug].tsx. This is very useful if you have a list of contacts and you want to show the details of one contact. Routes with higher specificity will be matched before a dynamic route. For example, contacts/victor will match app/contacts/victor.tsx before app/contacts/[user].tsx. Multiple slugs can be matched in a single route using the rest of the syntax (...). For example, app/contacts/[…rest].tsx matches /contacts/123/settings. Dynamic segments are accessible as search parameters in the page component. ` Conclusion In this article, we learned about the Expo Router, how it works, its core features, and its tradeoffs using some example codes. Expo Router offers a minimalistic API with a straightforward approach to navigation using the file-system routing concepts. The Expo router is most useful if you are not dealing with a complex navigation system in your project. File-based routing provides a smooth navigation experience for mobile applications, and Expo Router implements this solution into its library....

Jan 10, 2024

8 mins

ReactExpoReact Native

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

Shuchi Mittal, the Head of Cloud enablement at Honeywell, discusses how she as a leader in platform engineering has been able to transform internal platform engineering teams at other organizations by providing teams with value-added services, and how they effectively managed costs. She talks about how to treat these teams as customers, and delivering services that meet the customer needs, but also charging them for their usage. By providing policy-compliant infrastructure and unique services tailored to their requirements, platform engineering teams can showcase their commitment to supporting the success of other teams within an organization. This approach not only fosters trust but also positions platform engineering as a strategic partner rather than just a service provider. By going beyond the basic infrastructure provisioning, the platform engineering team can offer services that help development and product teams streamline their processes and improve efficiency. Shuchi shares her work at Fiserv where she implemented a chargeback system to track usage and costs effectively, incentivizing better development practices. This not only helped in managing costs but also encouraged teams to optimize their resource utilization, leading to improved overall efficiency and more easily scalable systems. Her platform engineering team recognized the importance of effectively managing financial aspects to secure upfront investment for product development. By implementing a billing system based on gigabyte hours, they aligned costs with usage, enabling teams to have a clear understanding of their resource consumption. This approach not only provided transparency but also incentivized teams to adopt cost-effective practices. By strategically managing financial aspects, the platform engineering team gained the trust of stakeholders and secured the necessary resources to drive innovation and deliver value to the organization. Shuchi’s journey of platform engineering serves as a valuable example of how a team can transition from being a basic service provider to becoming an innovation partner within an organization. By building trust, offering value-added services, and strategically managing financial aspects, the platform engineering team successfully elevated their role and became a strategic enabler of innovation. Download this episode here....

Apr 16, 2024

2 mins

Engineering LeadershipSoftware Engineering

How to Handle Async Data Fetching Using CreateResource in SolidJS

What is createResource?

How does createResource work?

Refetch and Mutate

Why is createResources special?

Conclusion

Victor Umeh

You might also like

Why Every Developer Should Try Elm, + Are We Abandoning JavaScript? with Lindsay Wardell

Overview of the New Signal APIs in Angular

File Based Routing with Expo Router

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

You might also like

Why Every Developer Should Try Elm, + Are We Abandoning JavaScript? with Lindsay Wardell

Overview of the New Signal APIs in Angular

File Based Routing with Expo Router

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal