Back

Redwood, a new framework

July 7th, 2022 · 5 min read

According to its documentation,

“Redwood is a full-stack web development framework designed to help you grow from side project to startup.”

Redwood features an end-to-end development workflow that weaves together the best part of React for developing pages and components, GraphQL as the query language for data, Prisma as ORM for accessing data, TypeScript for better programming, Jest for testing, and Storybook to aid with component development. It provides a full-stack development process in JAMStack.

Redwood is obsessed with developer experience and eliminating as much boilerplate as possible where existing libraries elegantly solve these problems, and where we don’t write our solution. The result has a Javascript development experience one can fall in love with!

Features

Let’s look at Redwood’s main basic features that make it look attractive as a full-fledged framework.

• Project Structure: Two folders are generated as API and Web when creating a Redwood project. API folder contains the GraphQL back end of your project, which runs on any server. The Web folder contains React front-end code; Redwood uses React for the front end, and several features are built around Routing, Components, Forms, and Cells, including unique formatting structures.

• Distinctive Command-Line: RedwoodJS CLI allows you to generate any file you need in the directory you specify. It includes two entry points, rw and rwt, which stand for developing an application and contributing to the frameworks, respectively. Also, you can use the CLI for migration and scaffolding purposes.

• Routing: Redwood Router is a customized version of React Router. It allows developers to track Routes with their corresponding pages by listing all the Routes in a single Routing file. The Named Routes feature allows you to add a reference name to each Route as you prefer. There are three main prop types in React Router name (used to call the route component from the link component), path (used to match the URL path to the route), and page (a prop that indicates the relevant component that needs to be rendered when the path is matched).

• Data Fetch with Cells: RedwoodJS cells are considered higher-level components that can handle data for you. If you are using RedwoodJS cells, you probably need to write the query then Redwood will do the rest for you. The data fetching mechanism is quite different from the typical traditional system. Redwood provides an asynchronous tool to fetch data where the front end and back end process their task separately, which makes the front end load without waiting for the data to be fetched. Let’s look at Redwood cells; they contain four states named Loading, Empty, Error, and Success, which are automatically rendered depending on the state of your cell.

• Integration with regular HTML: Redwood has identified the issue of React Forms and its complexities compared to a typical HTML Form, and has provided a solution which is a helper method as a wrapper to React Forms, around react-hook-form. With this method, it’s easier to validate client & server-side where you need to put the required styles to the imported input fields as follows:

Open Source Session Replay

OpenReplay is an open-source, session replay suite that lets you see what users do on your web app, helping you troubleshoot issues faster. OpenReplay is self-hosted for full control over your data.

Start enjoying your debugging experience - start using OpenReplay for free.

How Redwood works

In a typical setting, Redwood applications are split into two parts: a front end and a back end. This is represented as two JS/TS projects within a single monorepo. The front-end project is called the web side, and the back-end project is called the API side. The web side will end up running in the user’s browser, while code on the API side will run on the server.

Note: Redwood refers to ‘front end’ as ‘web’. This is because Redwood conceives of a world where you may have other sides like ‘mobiles’, ‘desktop’, ‘cli’, etc. But for the sake of this article, we’ll be referring to it as the front end.

The front end is built with React. Redwood’s router makes it simple to map URL paths to React ‘Page’ components. Pages may contain a ‘Layout’ component to wrap content and ‘Cells’ and regular React components. The Cells allow you to declaratively manage the lifecycle of a component that fetches and displays data. Other Redwood utility components make it insignificant to integrate forms and various basic needs.

The back end is an implementation of GraphQL API. Your business logic is organized into ‘services’ that represent their internal API and can be called both from external GraphQL requests and other internal services. Redwood can automatically connect your internal services with Apollo, reducing the amount of boilerplate you have to write.

Before we move on to building our Redwood project, let’s take a look at some of the basic commands of RedwoodJS CLI:

• yarn rw g page: generates a page component
• yarn rw prisma migrate dev: Runs migrations on our application
• yarn rw g sdl: generates a GraphQL schema definition file
• yarn rw g service: generates the service files
• yarn rw g cell: generates cell component
• yarn rw dev: runs Redwood dev server on http://localhost:8910/.

Building an app

We need to illustrate how to use RedwoodJS to build an app. The Todo app will be able to take notes and save those notes on the JSON server. Note: Credit to RedwoodJS for the example.

First steps

To create the project, all we have to do is run the following commands:

Let’s take a glance at our folder structure:

Defining data models

Now we have to add our Todo model to the schema.prisma file.

Note: Run yarn rw prisma migrate, which will prompt for the name of the migrations; just type added_todo and hit the enter button. Redwood will create and run the migrations.

We’ll create services that will be used to carry out CRUD operations on our todo table in the db:

This command will create the files:

• api/src/graphql/todos.sdl.js: contains the GraphQL schema definitions of our GraphQL endpoints.
• api/src/services/todos/todos.js: our service file contains all query and mutation resolver functions.

Creating the page and components

Our app will have just a page, i.e., the HomePage. The homepage will show the to-dos in the database and the input field.

This command creates the to-do page. The main file is located at web/src/pages/HomePage/HomePage.js. The page will map to the URL path ”/” home. We’ll also create a TodoListCell: yarn rw g cell list todo. It will generate files in the components folder. The main file is located at web/src/components/TodoListCell/TodoListcell.js.

We modify the code to this:

We’ll generate AddTodoControl component, which will have an input form with a placeholder and a submit button to submit our todos. Now, let’s scaffold the AddTodoControl component:

It creates a AddTodocontrol component located at web/src/components/AddTodoControl/AddTodoControl.js and our code should look like this:

We’ll create our TodoItem with the command yarn rw g component TodoItem and this component consists of our style attributes for each todo body, so we’re going to implement things like padding, borders, and lines with the code below:

The Check component consists of our icons like on, off, plus icons. To create the check component, run yarn rw g component. Input the following code in our Check component:

We need an AddTodo component to add new todos.

This is our final project.

Conclusion

There are many other reasons to get attracted to RedwoodJS.

• Opinionated defaults for formatting, file organization, Webpack, Babel, and more
• Generators for pages, layouts, cells, SDL, services, etc.
• Forms with easy client-and/or server-side validation and error handling
• Database and Data migrations

All these and many more make RedwoodJS unique to the core.

Resources