Introduction to Redwood.js: Rapid Application Development with React

One of the biggest challenges of building a web application is choosing the technologies you will use and integrating them into a work stack. Redwood.js is a React-based framework that provides an out-of-the-box stack, so you can just work with proven technologies that are already well integrated into the framework.

Redwood.js brings together React, GraphQL, and Prisma to manage your application’s UI, API, and data persistence. Surrounding this core are support tools and built-in features such as testing and logging; command line support for frameworks like Auth0 and TailwindCSS; and the ability to target both serverless and infrastructure-as-a-service (IaaS) deployments.

If you’re looking for an easier way to build React-based apps, Redwood.js might be a great choice. Read on for a hands-on introduction to Redwood.

Configure the Redwood Sample Application

To setup a new Redwood project, you will need yarm and current, active LTS version of Node.js installed on your development machine. Create a new application by entering the command shown in Listing 1.

Listing 1. Create a new Redwood.js application


yarn create redwood-app ./redwood-demo
cd ./redwood-demo
yarn rw dev

You will get the welcome screen shown in Figure 1 when you visit localhost: 8911 in your browser. (Parameters like port are configured with the redwood.toml config file.)

Screenshot of the Redwood.js welcome screen. IDG

Figure 1. The Redwood.js welcome screen.

Add a page to the Redwood command line

Redwood.js includes the ability to add pages and routes from the command line. The home page in Figure 1 is built into the framework, there is no actual file backing it up. We can create our own landing page by entering the following command:


yarn redwood generate page welcome /

Here you see the general shape of the Redwood commands. It says: generate a page called “welcome” with the root path (/). Now if you visit localhost: 8910you will get a very basic page saying “WelcomePage”. Redwood uses PascalCase in his translation of routes, and he adds the word Page. So our “welcome” route became “WelcomePage”. You can find the source of the page at /web/src/pages/WelcomePage/WelcomePage.js.

Routing with Apollo GraphQL

The WelcomePage itself isn’t very interesting yet, but we’re more interested in how Redwood handles routing. You can find your app’s routes in /web/src/Routes.jsas shown in listing 2.

List 2. /web/Routes.js


import { Router, Route } from '@redwoodjs/router'

const Routes = () => {
  return (
    
      
      
    
  )
}

export default Routes

Listing 2 shows you are using the Redwood.js router, which is similar to other solutions like React Router, but has specific characteristics. In general, each Route provides a mapping between the URL path and the page component that provides the content for this route.

A unique feature of the router is that it is controlled by the Apollo GraphQL state library. You can see how this is configured in /web/src/App.js, which is the main component of the application. Listing 3 shows the relevant part of the code.

Listing 3. Routing through Apollo GraphQL



      
        
      
    

Redwood hides most of the details from the app developer. It uses Apollo GraphQL to manage application state, including routing.

Add and link a page

We will create a new page to list song lyrics. To get started, add the page by typing the following on the command line:


yarn redwood generate page songs

Now you can create a link on the WelcomePage using the Link component, as shown in Listing 4.

Listing 4. Link to Songs page


import { Link, routes } from '@redwoodjs/router'
//...

Go to Songs

Now you can click the link and go to the Songs page, which also includes a basic welcome screen. Although we won’t cover that here, Redwood.js does support page layouts, which you can apply to many pages to reduce the need for boilerplate code.

Working with the Redwood.js backend

Now let’s look at the Redwood.js back-end. Uses of Redwood Prisma ORM to map to a database, and it includes SQLiteName as an on-site database for development. (Note that Redwood is similar to Blitz.js in this respect.) We can add a schema for our Songs page by opening the file at api/db/schema.prism and adding the entry shown in Listing 5. (You can delete the pre-existing sample, UserExample model.)

Listing 5. Adding Song and Songwriter models to Prisma/SQLite


model Song {
  id Int @id @default(autoincrement())
  name String @unique
  writers SongToWriter[]
}

If you’re unfamiliar with object-relational mapping tools like Prisma, you might be wondering what Listing 5 does. In essence, it creates a Song data model, which is used to perform the translation between the application and the data store. (See the Prisma documentation for learn more about data models in Prisma.)

Prisma will apply this new template to the SQLite schema when we enter the command: yarn rw prisma migrate dev. This command applies the schema for the dev database. (Note that Prisma will ask for a name for the migration. Any value will do. In a real project, you can use this name for restores.)

Add CRUD functions

Once Prisma is done, we can start using the model objects in our application as Prisma does the mapping work to and from the database. But Redwood.js does some of the heavy lifting for us by generating the create, read, update, and delete (CRUD) scaffold. Simply enter the following on your command line: yarn redwood generate scaffold Songs.

Now if you go back to /songs page, you’ll see that Redwood built us a basic UI based on the schema. Figure 2 shows an example of a basic user interface.

Redwood.js scaffolds CRUD operations for a new page. IDG

Figure 2. CRUD scaffolding on the Chunks page.

Therefore the scaffold The command creates a simple set of pages and components that we can use to create, update, and delete a Song entity. You can see the page files that Redwood.js uses to achieve the UI in /web/src/pages/Song/*. These page files, in turn, rely on the components found in /web/src/components/Song/*.

For example, take a look at /Song/SongPage/SongPage.js in list 6.

List 6. SongPage.js


import SongCell from 'src/components/Song/SongCell'

const SongPage = ({ id }) => {
  return 
}

export default SongPage

A cell is a special component that Redwood.js offers to simplify the management of the different states of a view (loading, empty, error and normal). This is a convenient way to manage state in a conventional way. You can learn more about cells in the Redwood.js documentation.

The SongCell looks like what you see in Listing 7.

List 7. SongCell.js


import Song from 'src/components/Song/Song'

export const QUERY = gql`
  query FindSongById($id: Int!) {
    song: song(id: $id) {
      id
      name
    }
  }
`
export const Loading = () => 
Loading...
export const Empty = () =>
Song not found
export const Failure = ({ error }) => (
{error.message}
) export const Success = ({ song }) => { return }

Here, the component exports several different functions, the output of which varies JSX elements. These functions are used by Redwood.js layouts to generate the correct UI based on state. Note that if successful, Redwood.js hands over the heavy lifting to the principal Song component, where all the real work is done. The Song The component works in a similar model, using GraphQL to get and manipulate data from the data store based on a data object that drives the view. (If you’re familiar with the MVC pattern, well here it is again.)

GraphQL

The app uses GraphQL to populate the data objects used by the UI. For example, in the SongCell component, the Song The component is parameterized with the song variable, which is hydrated by the graphql query (QUERY) at the beginning of the source. The request will use the URL’s ID slug.

As shown in Listing 8, Redwood.js generates GraphQL queries to support these use cases. Queries are stored in api/src/graphql/songs.sdl.ts.

Listing 8. songs.sdl.ts


export const schema = gql`
  type Song {
    id: Int!
    name: String!
  }

  type Query {
    songs: [Song!]! @requireAuth
    song(id: Int!): Song @requireAuth
  }

  input CreateSongInput {
    name: String!
  }

  input UpdateSongInput {
    name: String
  }

  type Mutation {
    createSong(input: CreateSongInput!): Song! @requireAuth
    updateSong(id: Int!, input: UpdateSongInput!): Song! @requireAuth
    deleteSong(id: Int!): Song! @requireAuth
  }
`

SDL files are schema descriptions for the GraphQL API. The main takeaway from List 8 is that a GraphQL endpoint exists for every bit of functionality around the Songthe CRUD functions of . These actions are the interaction point from front-end to back-end.

Conclusion

The good thing about Redwood.js is that it’s not afraid to make a number of key development decisions for us. From a developer’s perspective, this means easy take-off and more efficient development, especially in the beginning. Like all rapid application development frameworks, the key is to understand how the different program elements fit together as your application becomes more complex. At some point, you’ll probably need to make changes that go beyond what the framework understands.

Fortunately, Redwood.js largely stays within the confines of well-known technologies and conventions. You can use Redwood to create a React-GraphQL-Prisma-RDBMS application with sensible defaults, which can serve as a launch pad for developing more specific requirements.

Redwood is designed to facilitate deployment on different types of hosts. In particular, it is possible to deploy in serverless environments like Netlify or Vercel.

By the way, I found building with Redwood.js reminiscent of Ruby on Rails. It’s been a minute since I’ve used this frame, but it came to mind. As it turns out, Ruby on Rails inspired Redwood.js. So if you are a Rails fan, check out Redwood.js.

Copyright © 2022 IDG Communications, Inc.


Source link

Comments are closed.