Javascript

Introducing the new Expo, Styled Components, and Zustand Starter Kit

Apr 26, 2023

4 min read

Intro

We are delighted to announce our brand new Expo React Native starter kit to our Starter.dev kits collection. We built this starter kit to enable our team members who work mostly with web technologies to make an easy transition for them to work on native mobile apps with their current knowledge without any extra effort.

This Starter kit contains:

Expo a React native wrapper.
Styled Components lets you write actual CSS in your JavaScript-like web.
Zustand A small, fast, and scalable barebones state-management solution.
TypeScript JavaScript with syntax for types.
Jest is a delightful JavaScript Testing Framework with a focus on simplicity.
React Navigation Routing and navigation for Expo and React Native apps.

Problems This Kit Addresses

React Native Styling

One of the most difficult things for React Native beginners is its styling system. It's difficult for people who come from a web background because it’s not similar to CSS at all. It has different units, and each property accepts a different value. For more information visit React Native Style Documentation styled-components/native fixed that problem, you literally write CSS like for web and it translates the CSS code to a React Native Styles without any extra effort.

Thanks to the Expo team, we can use the React Native components cross-platform, even with frameworks like Next.js. This saves teams a lot of work. Instead of building the same feature twice, one for the web and the other for the mobile apps, we only build it once.

Let me show you an example:

A lot of libraries in the React ecosystem use the setImmediate() API (like react-native-reanimated). It’s a method used to break up long-running operations, and run a callback function immediately after the browser has completed other operations such as events and display updates, which Next.js doesn't polyfill by default. To fix this, you can polyfill it yourself.

First, we need to install set immediate package

yarn add setimmediate

Then import it in the app root pages/_app.js

import 'setimmediate';

Use the @expo/next-adapter in the next.config.js

const { withExpo } = require('@expo/next-adapter');

module.exports = withExpo({
  /* next.config.js code */
});

Add image support with next-images

const { withExpo } = require('@expo/next-adapter');
const withImages = require('next-images');

module.exports = withExpo(
  withImages({
    projectRoot: __dirname,
  })
);

Add font support with next-fonts

const { withExpo } = require('@expo/next-adapter');
const withFonts = require('next-fonts');

module.exports = withExpo(
  withFonts({
    projectRoot: __dirname,
  })
);

Now you can use your Expo React Native components in Next.js site.

We use React Navigation in almost every project we work on, it’s a necessary piece of the app, so we already set it up so you can start your new app quickly.

We also grouped the screens under the src/screens directory, where each screen has its own folder with its related files.

Defining a better organization pattern for components to scale your app

We structured this project from our experiences with big React projects. One challenging part of using React is that it gives the developer a lot of freedom to choose their own file structure. However this is not good on a bigger app scale, because every developer has their own way to organize the files, and with a big React project that a lot of developers are working on, we usually end up with a mess. We figured this structure out from the previous projects we built.

Imagine we have a component, and this component has different files like, testing, …etc

Our way to structure the components is:

Each component has its own folder:

components/
	FirstComponent/
	SecondComponent/

Each folder has the component files

components/
	FirstComponent/
		FirstComponent.tsx
		FirstComponent.test.tsx
		FirstComponent.stories.tsx

// …etc
	SecondComponent/
		SecondComponent.tsx
		SecondComponent.test.tsx
		SecondComponent.stories.tsx

// …etc

The problem now is the importing sentences gonna be ugly like this:

import FirstComponent from ‘./components/FirstComponent/FirstComponent’;

So it solve this, we add in each Component folder an index.ts file with the following:

export { default } from ‘./FirstComponent’;

Now the folder structure will look like this:

components/
	FirstComponent/
		Index.ts	<- To solve the import sentences 
		FirstComponent.tsx
		FirstComponent.test.tsx
		FirstComponent.stories.tsx

// …etc
	SecondComponent/
		Index.ts	<- To solve the import sentences 
		SecondComponent.tsx
		SecondComponent.test.tsx
		SecondComponent.stories.tsx

// …etc

Now the import sentence will be much cleaner:

import FirstComponent from ‘./components/FirstComponent’

This can help keep your files and folders organized, and help scale your codebase with time.

Conclusion

This starter kit is the result of a lot of experience we gained on React projects we built internally and for clients. It helps you to start quickly without going through the tedious task of installing and setting up dev tools, and at the same time, it helps your app scale more easily.

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.

Mark Shenouda

@MarkSShenouda @markshenouda

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

State of React Wrap-up | April 26, 2022

In this State of React event, the main topic focused on the React 18 release. Our panelists had a lot of thoughts on the release, its latest features, and the React working group. We also got an update on the state of Redux, and heard about our panelists' experiences at the 2022 React Miami conference. Here is a complete list of the hosts and panelists that participated in the online event. Hosts - Dustin Goodman, Engineering Manager, This Dot Labs, @dustinsgoodman - Dane Grant, Senior Software Engineer, This Dot Labs, @danecando Panelists - Jen Luker, Senior Staff Frontend Engineer, Nav, Inc., @knitcodemonkey - Ben Ilegbodu, Frontend Architect, Stitch Fix, @benmvp - Romello Goodman, Educator at MICA & Senior Engineer, Shopify, @mellogood - Kathleen McMahon, Senior Design Systems Engineer, Northwestern Mutual, @resource11 - Chantastic, DX Engineer, Chromatic, @chantastic - Mark Erikson, Senior Front-End Engineer, Replay, @acemarke You can watch the full State of React event on the This Dot Media YouTube Channel. React 18 is finally here!!! The conversation got started with the panelists sharing their thoughts on the latest release and why they felt like it was a little bit anti-climatic. After years of hard work and anticipation, the final release didn't generate as much noise in the community as previous versions of React. Some of the panelists believe that a lot of the blog posts and conversations about the latest changes happened months ago. This might have contributed to a quiet release this time around. There was also praise for the React 18 working group which did a great job of communicating with the community over the years about progress of the new version. They also tried to incorporate a lot of the community feedback into this latest release. The hard work and care of the React 18 working group also contributed to the quiet and stable release of this latest version. Does the anti-climatic release of React 18 signal that people are tired of React? There was a question posed to the group that maybe people were tired of React and that is why it was anti-climatic. But the panelists believe that this quiet release means that React is becoming more of a standard in the JavaScript ecosystem. They also brought up the good point that a lot of developers have already been working with some of the new features before the official release date. What do the panelists think about the new features of React 18? One of the panelists expressed interest in trying out the new useTransition hook which allows you to specify some states as a lower priority. But they also made the point that there wasn't an immediate need in their current projects to incorporate some of the newer features. Sometimes you are comfortable working in your codebase and it is fine to use the existing hooks that are already there. It might become a situation where new developers learning React for the first time will push for the use of these new features. This led to conversation about how React 18 helped solve a lot of problems that library authors were experiencing. For example, the new concurrent suspense and transition APIs will make it easier for loader indicators. But there was another hook mentioned that peaked the interest of some of the panelists. The useId hook generates a unique random ID that is consistent in server side and client side rendering. The panelists were excited about how easy it was to use and how it would improve on accessibility. They were also grateful that the name was changed from useOpaqueIdentifier to useId. Will the React working group continue? There are no current plans for the React working group, and it has been relatively quiet since the release. But the panelists do believe that this group set the tone for future major releases. As mentioned earlier, the React working group did a great job working with the community and creating a smooth transition from React 17 to React 18. What are some of the new features that developers need to learn before migrating to React 18? The first feature that was mentioned was the new root API. In React 17, this is how you would render your App component. ` But with React 18, you would use the new createRoot API. ` Another feature that was mentioned was flushSync which allows you to opt out of automatic batching. The State of Redux with Mark Erikson At this point of the conversation, we transitioned into a short powerpoint presentation on the state of Redux. Here are the key points mentioned in that presentation. - React-Redux v8.0 is now live. - Redux JS/TS templates for Create React App have been updated. - This new version works with React 16.8, 17, 18 and React Native - React-Redux v8.0 has been converted to TypeScript - Redux Toolkit 1.8 has a new "listener" side effects middleware which allows you to do powerful async/await workflows. - Redux 4.2.0 has officially marked createStore as deprecated Should people start migrating over to React 18 now or is there a waiting period? During this part of the conversation panelists talked about what is supported by React 18. For example, if your application uses Enzyme for testing, then it will not be supported by React 18. This would require you to rewrite all of your tests just to accommodate this latest version. Developers need to understand what is supported by this new version before migrating over. The panelists also pointed out that it will take a few months of the community working with React 18 before potential issues come to light. What was React Miami like? What was it like to have in person conferences again? I think Mark Erikson had the best quote to sum up the 2022 React Miami conference. "Warm, fun, awesome, tiring, weird" Well, that works for me. :) But in all seriousness, both Ben and Kathleen gave talks and enjoyed their time at the conference. The general consensus was that it was nice to connect with the community again in person, even if it was weird at times. Are there any new exciting courses or articles coming out for React 18? There was a lot of a great discussions in the React working group GitHub repository. A lot of authors were able to create great blog posts out of those discussions. There was also a quick shout out to Dustin and Dane for their involvement with the new React beta site. You can learn more about that in this Meta case study. The downside of React being unopinionated Mark brought up the issue he has seen with React developers not knowing what to use for styling, state management and build tools. Since React is unopinionated, there should be a place where developers can learn about the common technologies that work well with React. Luckily for us, This Dot Labs has created a tool to tackle this issue. react.framework.dev is a community driven list of resources for React. Accessibility matters In the closing conversation, there was a lot of discussion on how the new Rect 18 features will improve on accessibility. The panelists also felt like all developers should care more about creating well built accessible applications and take the time to learn about best accessibility practices. Conclusion This was an incredible conversation with a great group of panelists and I would highly suggest you watch the video. You can watch the full State of React event on the This Dot Media YouTube Channel....

May 3, 2022

6 mins

ReactReact Native

Introducing the New Shopify and Next.js 13 Starter Kit

Intro We are delighted to announce our brand new Shopify and Next.js 13 starter kit to our Starter.dev kits collection. This Starter kit is amazing to help you and your team quickly bootstrap a custom Shopify storefronts powered by Next.js 13 App Router since it has almost every feature you need for production set up and running! Why did we build it? At This Dot Labs, we work with a variety of clients, from big corporations to startups. Recently, we realized that we have a lot of clients who use Shopify that want to build custom stores using Next.js to benefit from its features. Additionally, we know that Hydrogen Shopify has only been limited to Remix since they acquired it. We had a lot of a hard time refilling the gap Hydrogen left to implement its features from scratch in our client projects. And from here, we realized that we need to build a starter kit to: - Help our teams build custom storefronts using Next.js Quickly - Reduce the cost for our clients There were a lot of Next.js Shopify starters out there, but they were very basic and didn’t have all the features our teams needed, unlike the Official Hydrogen Starter Example which is complete. So, we decided to convert the Hydrogen starter from Remix/Hydrogen to Next.js, and use the power of the App Router and React Server Components. Tech Stack We used in this project: - Next.js 13 - TailwindCSS - Zustand Why Shopify Shopify is a great e-commerce platform. They have a lot of experience in this field since 2006, and now over 4.12 million e-commerce sites are built with Shopify. (Source: Builtwith.com.) Shopify is used by online sellers in over 175 countries around the world, with 63% of Shopify stores estimated to be based in the US. Why Next.js 13 As we mentioned above, we have a lot of clients who already use Next.js and it’s a very popular framework in the market for its flexibility, scalability, and diverse collection of features. Features Since this starter kit is based on the official Shopify Hydrogen template, it has all of it’s features as well including: - Light/Dark themes support - Authentication system with login, register, forgot password, and account pages - Supports both Mobile/Desktop screens - Has built-in infinity scroll pagination, built with Server Components - State management using Zustand - Variety of custom fonts - All components have been built with Tailwind - Static analysis testing tools pre-configured like TypeScript, Eslint, Prettier, and a lot of useful extensions - Storybooks for the consistency of the system design - GitHub Pull requests and release templates - Shopify analytics integrated with the kit - Great performance and SEO scores - And finally, incompatible performance tested by both Lighthouse and PerfBuddy Performance This kit is running at top performance! It has amazing performance, SEO, and accessibility scores. We tested it using PerfBuddy, and the results are incredible on both Desktop and Mobile. Here is the full report. > Note: PerfBuddy is an incredible free tool to analyze the performance of your web apps accurately. Check it out! Also, the results from Lighthouse are pretty fascinating: When do I use this kit? This starter kit is great for starting new custom storefronts rapidly, especially for startups to save time and money. Also, it can be used to migrate from the old Next.js storefront to the new App router directory as it has all of the examples your team will need to integrate Shopify in Next.js 13 Conclusion We are very excited to share this starter kit with you, and we hope you find it useful for your projects. We are looking forward to hearing your feedback and suggestions to improve it, and add more features to it. Also, we are planning to add more starter kits to our Starter.dev collection, so stay tuned for more updates!...

Aug 4, 2023

4 mins

NextJSShopify

Intro to EdgeDB - The 10x ORM

Intro to EdgeDB - The 10x ORM I’ve written a couple of posts recently covering different TypeScript ORMs. One about Prisma, and another about Drizzle. ORM’s are a controversial topic in their own right - some people think they are evil, and others think they are great. I enjoy them quite a bit. They make it easy to interact with your databases. What is more important and magical for an application than data? SQL without an ORM is amazing as well, but there are some pain points with that approach. Today I’m excited to write about EdgeDB, which isn’t _exactly_ an ORM or a database from my perspective (although they call themselves one). It is, however an incredibly impressive piece of technology that solves these common pain points in a pretty novel way. So if it’s not an ORM or a database, what exactly is it? I don’t think I can answer that in one or two sentences, so we will explore the various pieces that make up EdgeDB in this article. From a high-level standpoint, though, an interface/query language that sits in front of PostgreSQL. This may seem like some less important implementation detail, but in my eyes, it’s a feature and one of the most compelling selling points. Data Modeling EdgeDB advertises itself as a “graph-relational database”. The core components of EdgeDB data modeling are the schema, type system, and relationship definitions. A schema will consist of objects that contain various typed attributes and links that connect the objects. In SQL, a table is analogous to an Object, and a foreign-key is associated with a link. Here’s what a simple schema in EdgeDB looks like ` There’s a few things to highlight here * We defined two different objects (tables) User and Post * Each object contains properties with their types defined * str is one of several scalar types (bool, int, float, json, datetime, etc) * the author property is a required link to the User object Defining relations / associations In our example above we defined a one-to-many relationship between a user and posts. All the relation types that you can define in traditional SQL are available. One interesting feature though is called backward links. These can be defined in your schema and it allows you to access related data from both sides of a relationship. ` likes are a many-to-many relationship between Tweet and User. With a backlink defined multi link likers := Tweet.<likes[is User]; - we can access likes from a User and likers from a Tweet. ` That's how we can access these relations in our queries. You might be looking at these queries and thinking it looks a lot like GraphQL. This is why they call it a ‘Graph-relational’ database. We’ve only scratched the surface of EdgeDB schema’s. Hopefully, I’ve at least managed to pique your interest. Computed properties Computed properties are a super powerful feature that can be added to your schema or queries. This example user schema creates a computed discriminator and username property. The discriminator uses an EdgeDB standard library function to generate a discriminator number and the username property is a combination between the name and discriminator properties. ` Globals and Access Policies EdgeDB allows you to define global variables as part of your schema. The most common use case I’ve seen for this is to power the access policy feature. You can define a global variable as part of your schema: global current_user: uuid; With a global variable defined, you can provide the value as a sort of context from your application by providing it into your EdgeDB driver/client. ` You can then add access policies directly to your schema, for example, to provide fine-grained access control to blog posts in your blogging application. ` Aside from access policies, you can use your global variables in your queries as well. For example, if you wanted a query to select the current user. ` Types and Sets EdgeDB is very type-centric. All of your data is strongly typed. We’ve touched on some of the types already. * Scalars - There are a lot of scalar types available out of the box * Custom scalars - Custom scalar types are user-defined extensions of existing types * Enums - Are supported out of the box - enum<Admin, Moderator, Member> * Arrays - Defined by passing the singular value type - array<str>; * Tuples - In EdgeD, tuples can contain more than 2 elements and come in named and unnamed varieties - <str, number>; tuple<name: str, jersey_number: float64, active: bool>; All queries return a Set which is a collection of values of a given type. In the query language, all values are Sets. Sets are a collection of values of a given type. A comma-separated list of values inside a set of {curly braces}. A query with no results will return an empty or singleton set. If we have no User values stored yet - select User returns {}. Paired with the query language types and set provides an incredibly powerful and expressive system for interacting with your data. If you thought TypeScript was cool, wait until you start writing EdgeQL! 🙂 EdgeQL Now to the fun stuff: the query language. We’ll use a schema from the docs and start by looking at some of those queries and build on those. The example schema has an abstract type Person with two sub-types based on it Hero and Villian. This is known as a polymorphic type in EdgeDB. The Movie type includes a 1:m association with Person ` Selecting properties / data Before we dig into some real queries we should just touch on how we select actual data from a query. It’s pretty obvious and GraphQL-like but worth mentioning. To specify properties to select, you attach a shape. This works for getting nested link / association data as well. Based on our schema, here’s how we could select fields from Movie, including data from the collection of related characters. ` There is also a feature called a splats that allows you to select all fields and/or all linked fields without specifying them individually. ` If you don’t specify any properties or splats, only id’s get returned select Movie; . Adding some objects with insert To get started, we can use insert to add objects to our database. We’ll start big by looking at the nested insert example. This example is interesting because it shows the creation of two objects in a single query. You’ll notice the simplicity of the syntax. Even though this is the first EdgeQL query we’re looking at, in my experience, it’s like this across the board. I’ve found EdgeQL queries to be simple and intuitive to the point where I’ve been able to intuit how to accomplish things in my head without having to reference the docs or ask the AI. This example adds a new Villian and a new Hero which gets assigned as a link or association to the nemesis field on our Villian. To accomplish this we see that we can nest queries by wrapping them in (). ` The next example is pretty similar, but instead of creating the linked property, we are select ing and adding several potential objects to the characters list of Movie since it is a multi link. This is a pretty complex query that is doing a lot of different things. It’s deceivingly succinct. To accomplish the same thing with SQL this would probably be about 3 different queries. This query finds the objects to add to the characters multi link by filtering on a collection of different strings to match against the name property. ` The last thing we’ll cover for insert is bulk inserts. This is particularly useful for things like seed scripts. In this example, you can just imagine that you have a JSON array of objects with hero names that gets passed in as an argument to your query ` Querying data with select We’ve already seen subqueries and a select in the last section where we found a collection of Person records with a filter. We’ll build on that and see what tools are available to us when it comes to querying data. This one covers a lot of ground. Very similar to SQL we have order and limit, and offset operators to support sorting and pagination. Also there is a whole standard library of functions and operators like count that can be used in our queries. This example returns a collection of villian names, excluding the first and last result. ` Most commonly, you will want to filter by an id ` Here’s another common example filtering by datetime. Since we’re using a string value here we need to cast it to the EdgeDB datetime type. ` You get a pretty similar toolbox to SQL when it comes to filtering with your common operators and things. Combined with all the tools in the standard library, you can get pretty creative with it. Changing values and links with update The update..filter..set statement is how we can update existing data with EdgeQL. set is followed by a shape with assignments of properties to be updated. ` You can replace links for an object ` or add additional ones ` An even more interesting example is removing links matched on a type. Since Villian is a sub-type of Person , this query will remove all characters linked of the Villian type. ` Deleting objects with delete Deleting is pretty straight forward. Using the delete command you can just filter for the objects that you would like to remove. ` When the EdgeQL pieces fall into place As you become more familiar with the EdgeQL query language chances are you’ll start writing very complex queries fluently because everything just makes sense once you’ve learned the building blocks. Domain and business concerns I don’t think they explicitly mention this as a goal anywhere but it’s something that I picked up on pretty quickly. EdgeDB nudges you to move more of what might have traditionally been application logic into your database layer. This is a topic that can bring a lot of division since even things like foreign keys and constraints in SQL are frowned upon in some circles. EdgeDB goes as far as providing constraints, global variables, contexts, and authorization support built into the database. I think that the ability to bake some of these concerns into your EdgeDB Schema is great. The way you model your schema and database in EdgeDB map to your domain in a much more intuitive way where domain concerns don’t really feel out of place there. Database Clients and Query Builders and Generators We’ve covered a lot so far to highlight what EdgeDB is and how to handle common use cases with the query language. To use it in your project though, you will need a client/driver library. There are clients available in several different languages. The one that they clearly have put the most investment into is the TypeScript query builder. We’ll briefly look at both options: simple driver/client and query builder. Whichever you end up choosing you will need to instantiate a driver and make sure you have a connection to your database instance configured. Basic client Although the TS query builder is very popular and pretty amazing, I couldn’t get away from just writing EdgeQL queries. In my application, I composed queries using template strings, and it worked great. The clients all have a set of methods available for passing in EdgeQL queries and parameters. querySingle is a method for queries where you are only expecting a single result. If your query will have multiple results you would use query instead. There is also a queryRequiredSingle which will throw an error if no results are found. There are some other methods available as well including one for running queries in a transaction ` The first argument is the query, and the second is a map of parameters. In this example we include the title parameter and it is accessed in our query via $title. TypeScript query builder If you have a TypeScript app and type-safety is important, you might prefer using the query builder. It is a pretty incredible feat of TypeScript magic initially developed by the same developer behind the popular library Zod. We can’t cover it in very much depth here but we’ll look at an example just to have an idea of what the query builder looks like in an application. ` The query builder is able to infer the result type automatically. It knows which fields you’ve selected, it knows that the result will be a single item. Query generator There are generators for queries and types. So even if you opt out of using the query builder you can still have queries that are strongly typed. It’s nice to have this option if you want to just write your queries as EdgeQL in .edgeql files. ` We end up with an exported function named getUser that is strongly typed. ` Tools and Utilities The team at EdgeDB puts a big emphasis on developer experience. It shows up all over the place. We’ve already seen some utilities with the generators that are available. There are some other tools available as well that help complete the entire experience. EdgeDB CLI The first and most important tool to mention is the CLI. If you’ve started using EdgeDB then you’ve most likely already installed and used it. The CLI is pretty extensive. It includes commands for things like migrations, managing EdgeDB versions and installations, managing projects and local/cloud database instances, dumps and restores, a repl, and more. The CLI makes managing EdgeDB a breeze. Admin UI The CLI includes a command to launch an admin UI for any project or database. The Admin UI includes a awesome interactive diagram of your database schema, a repl for running queries, and a table to inspect and make changes to the data stored in your database. Summary Adopting newer database technology is a tough sales pitch. Replacing your application’s database technology at any point in its lifecycle is not a problem that anyone wants to have. This is one of the reasons why EdgeDB being a superset of PostgreSQL is a huge feature in my opinion. The underlying database technology is tried and true, and EdgeDB is open-source. Based on this, I would feel confident using EdgeDB if it aligned well from a technical and business perspective. We’ve covered a lot of ground in this post. EdgeDB is feature-packed and powerful. Databases is a tough nut to crack, and I commend the team for all their hard work to help continue pushing forward one of the most important components of almost any application. I’m typically pretty conservative when it comes to databases, but EdgeDB took a great approach, in my opinion. I recommend at least giving it a try. You might catch the EdgeDB bug like I did!...

Apr 26, 2024

11 mins

JavaScriptEdgeDB

Introducing the new Expo, Styled Components, and Zustand Starter Kit

Intro

Problems This Kit Addresses

React Native Styling

Skip the Tedious Steps of Installing React Navigation

Defining a better organization pattern for components to scale your app

Conclusion

Mark Shenouda

You might also like

File Based Routing with Expo Router

State of React Wrap-up | April 26, 2022

Introducing the New Shopify and Next.js 13 Starter Kit

Intro to EdgeDB - The 10x ORM

You might also like

File Based Routing with Expo Router

State of React Wrap-up | April 26, 2022

Introducing the New Shopify and Next.js 13 Starter Kit

Intro to EdgeDB - The 10x ORM

Intro

Problems This Kit Addresses

React Native Styling

Share Components Across Platforms

Skip the Tedious Steps of Installing React Navigation

Defining a better organization pattern for components to scale your app

Conclusion

Mark Shenouda

File Based Routing with Expo Router

State of React Wrap-up | April 26, 2022

Introducing the New Shopify and Next.js 13 Starter Kit

Intro to EdgeDB - The 10x ORM

File Based Routing with Expo Router

State of React Wrap-up | April 26, 2022

Introducing the New Shopify and Next.js 13 Starter Kit

Intro to EdgeDB - The 10x ORM