Update (2020): This tutorial has been updated for Dart 2.0 and OverReact 2.0 š
There are a million different ways to build a web app in today's landscape. Different languages and frameworks come and go and vary in popularity. There isn't one right way to do things and ultimately it's about weighing the pros and cons of the available tools at your disposable. The goal of this document is to inform you about another option you may have not previously considered: using React with Dart.
Table of Contents
- What is Dart?
- Why React?
- Requirements
- Getting Started
- Building & Running
- Dart Development Environment
- Building the Application
- Testing
- Continuous Integration
- Deploying
- Your Turn
- Additional Resources
What is Dart?
Dart is a programming language originally developed by Google for building complex web applications. It's a statically-typed alternative to JavaScript that compiles to JS for use in the browser. It's open-source, easy to learn, and easy to scale. But wait, there's more!
- Strong IDE integration (code completion, code navigation, static analysis, etc.)
- Strong core set of common libraries (async, collections, isolates, etc.)
- Excellent development ecosystem
- Multi-threading support
- And much, much more
Google uses Dart for AdWords which makes up the majority of Google's revenue. It's also the language used at Workiva for their next-generation products. Workiva has committed to using Dart and has published a variety of OSS (open-source software) libraries to make developer's lives easier. If you're curious, here's a list of some companies who use Dart.
Why React?
As I mentioned at the start of this article, it's important to thoroughly evaluate all of the different framework options before choosing what's right for your team or company. I won't go too in-depth here on React vs. Angular since there are a variety of articles that dive into specifics, but I will note a couple wins for React:
- Uni-directional data flow
- Declarative nature of rendering views
- XML-like syntax called JSX
Requirements
Let's assume we are given some requirements to create a todo list as shown below. To help us "think" in React, I've outlined the design with boxes for each React component.
Getting Started
The IDE you choose is mostly personal preference, but here are some I suggest for Dart:
You can clone the git repository with the todo application by running:
Installing Dart
You can install Dart on macOS using Homebrew.
Serving Dart applications in a Web browser is done using the webdev
command. This should be activated globally - instead of on a project-by-project basis:
Building & Running
The Dart SDK comes with a tool called pub
to help manage your codebase. The most common command pub get
is used to download a package's dependencies. This is the first thing you will need to do when checking out an
existing Dart repository.
In addition to getting dependencies, you simply need to serve the application to view it in a browser:
Now, we can open up http://localhost:8080/ to see the todo application.
Building vs. Serving
Some Dart libraries (like over_react
) - use builders to generate files "under the hood". When you first
open a project that contains over_react components in an IDE like Webstorm - you may see a bunch of
analysis errors in the "Dart Analysis" tab - even after you run pub get
. This happens because there are
references to objects that have not been built yet. In order to get rid of the analysis errors in your IDE,
run pub run build_runner build
from the root of the project, then restart the analysis server. Note that
serving the app via webdev serve
will also perform the same build.
Dart Development Environment
The Dart SDK ships with tools to help you hit the ground running instead of having to set up your own development and build environments for each project. These tools provide dependency management, code compilation / minification, and debugging support out of the box.
Directory & File Structure
Dart has a prescribed directory structure in order to ensure that its tools work out of the box.
lib/
- Contains all internal implementation code.
test/
- Contains all unit, integration, and functional tests.
tool/
- Contains development tools, scripts, and configuration.
web/
- This directory is served by default when running the application. It is common to
include an
index.html
file in this directory.
- This directory is served by default when running the application. It is common to
include an
pubspec.yaml
- This file defines all the metadata about your package such as name, version, authors, dependencies, etc.
pubspec.lock
- This file specifies the version of each dependency installed in the project.
It will be automatically updated when dependencies change in
pubspec.yaml
or by runningpub upgrade
. It should only be committed in application packages
- This file specifies the version of each dependency installed in the project.
It will be automatically updated when dependencies change in
dart_dev
dart_dev is a centralized tooling package built on top of the Dart SDK. All Dart projects eventually share a common set of development requirements:
- Tests (unit, integration, and functional)
- Code coverage
- Consistent code formatting
- Static analysis to detect issues
- Documentation generation
The Dart SDK provides the necessary tooling to accomplish the tasks mentioned above but lacks a consistent usage pattern across multiple projects. Using dart_dev, a single configuration file will get our project configured and ready to use a variety of command line arguments.
For example: let's format the entire code base.
To make things even more simple, we can set up a bash alias
which turns the previous command into:
Building the Application
Now that we have an understanding of the language/tools we're working with, let's start creating the application! We will be utilizing some of Workiva's OSS.
OverReact
OverReact is a library for building statically-typed React UI components. Since OverReact is built on top of React, I strongly encourage you to gain familiarity with React first if you're not by reading this tutorial. The example below compares a render()
function for JSX and OverReact that will have the exact same HTML markup result.
React (JSX):
OverReact (Dart):
OverReact helps bridge the gap between Dart and React. If you're using VS Code, you can utilize OverReact code snippets to help speed up your development. Now, let's talk about our front-end architecture.
w_flux
w_flux is an architecture library with uni-directional data flow that provides an MVC like architecture and works well with React UI components.
This library was inspired by RefluxJS and Facebook's Flux. The same general principles apply here. For more information, please read the README in the w_flux repository.
Defining Dependencies
As previously mentioned, we'll use the pubspec.yaml
file in our root directory to define the dependencies for our project. Let's take a look at the pubspec.yaml
for the todo list.
This file tells pub
which versions of the included packages it needs to retrieve. You can find more information about what all can be included in this file here.
/web/
Inside the web
directory, we'll find the entry point into our application. This file sets up the Actions
and Store
for our Flux architecture. Then, it creates a new TodoApp
component and renders it into our container.
The container previously mentioned is the DOM node with an id
attribute value of app-container
as shown below. You'll notice I've included Bootstrap to handle the styling our of UI components.
/lib/src/
Let's take a look at actions.dart
. This file defines the available operations we can perform.
You'll notice some actions take a Todo
parameter. Let's define the structure of our Todo
model.
Each Todo
object can be initialized with some content and has a completed state which is initially false
.
/stores/
We now have some actions to dispatch. Next, we need a store to contain our application's data. For this example, we only need one store.
Note: For larger applications, you will generally have multiple stores. Review the w_flux README for more information.
When our TodoStore
is constructed, it populates our todo list with some pre-defined Todo
objects. It also connects our actions to the store using triggerOnAction()
. This function will re-render all components that are watching the store after the action has completed. You'll also notice we have a public getter to obtain the list of todos.
To summarize so far, we have:
- Initialized an entry point into the application
- Defined actions for the todo list
- Created a data model for a Todo item
- Set up a store to contain the application's data
/views/
The final piece will be the OverReact UI components to display the store's data. We defined a top-level TodoApp
component in main.dart
. This is what we refer to as a "container" component. It subscribes to our store and dispatches actions. It does not handle displaying UI components.
Note: If the structure of this component is confusing, please review the anatomy of an OverReact component.
The TodoList
component is a "presentational" component. It has no knowledge of any stores/actions and simply renders the data passed along as props and uses callbacks to communicate with the store. Let's take a look at the renderListItems()
function of the TodoList
component.
Based on the todo data passed in as props, this function creates a new list of TodoListItem
components to be rendered. Those components will render as follows:
The ListGroupItem
component is taken from the OverReact examples. It models the list group component from Bootstrap. You can find more OverReact example components located in lib/src/todo_dart_react/components
.
You'll notice we've added a test ID to the Button
component using ..addTestId()
. Let's talk about how we can unit test this component.
Testing
All of the test files are located in the test/
directory. For this example, I've only created unit tests. You could also create integration and functional tests here as well. Testing OverReact components is simple using over_react_test. Let's look at how we can test our TodoListItem
component to check it properly calls deleteTodo
when the button is clicked.
todo_list_item_test.dart
This test creates a new handler for deleting a todo and passes it to the TodoListItem
when rendering. Then, we can retrieve the delete button from the DOM of the rendered instance and simulate clicking the button. Finally, we can expect that the handler was successfully called.
Note: We don't need to test what happens when a todo is deleted here. For separation of concerns, we should unit test that it is successfully removed from the store in todo_store_test.dart
.
We can now run all unit tests using the following command:
Continuous Integration
Continuous Integration (CI) is the process of automating the building and testing of your code every time you commit changes to GitHub. We can utilize Travis CI to easily perform static analysis, check formatting, run unit tests, and generate code coverage using a .travis.yml
file. You don't need to worry about configuring this file - it's already all set up and running in this repository. If you fork the repo to create your own application, you will need to sync Travis CI with your GitHub account to trigger builds when you commit changes.
Deploying
When you're ready to compile your code to JS, we can use pub run build_runner build -r
.
The -r
flag stands for "release" - and uses dart2js
to compile Dart into a single JS bundle.
dart2js
will automatically remove any dead code or unused libraries. By default, the
compiled code is output to .dart_tool
.
Netlify
Netlify makes it extremely easy to deploy your compiled code. You can create an account for free and have the ability to upgrade to utilize features like custom domain names, SSL, and more. Let's look at how we can deploy our todo application from the command line.
Note: This will create a .netlify
file which you might want to commit for your application.
That's it! š We can modify the settings for our site on Netlify to change the site name. You can view the deployed todo app at https://dart-react-todo.netlify.com/.
Your Turn
The todo list isn't fully completed per our requirements. To fully finish the application, you'll need to:
- Mark todos as completed when the checkbox is clicked
- Add an action for clearing all completed todos
- Modify the
TodoStore
to listen to the new action - Create the
TodoFooter
component - Hook up the buttons in the footer to the store
- Use icons inside the buttons
You can view the entire source code here. Thanks for reading!