When shipped with Windows 3.1 it wasn’t simply to entertain. The addictive little game masked an ulterior motive: . The two-button mouse is old news by now, but Minesweeper remains just the right size for a different introduction. Minesweeper introducing users to the right button of the mouse Over the next fifteen minutes, we’ll build a Minesweeper clone ( ) that uses , , and to build a robust browser application. It’s a simple, synchronous project, but it’s enough to introduce patterns that use to help tame the complexity of much larger applications. github TypeScript React Redux Redux and TypeScript Getting Started No time for configuration—the clock is ticking! We can use to set up a project with sensible defaults. Fine tuning can come later. create-react-app-typescript $ create-react-app minesweeper — scripts-version=react-scripts-ts$ cd minesweeper$ yarn install We’ll also need to add , , and for the latter ( brings ). redux redux-react type definitions redux its own $ yarn add redux react-redux$ yarn add @types/react-redux Game Logic Next, we’re going to cheat (but only a little). While we’ll use React for the frontend UI and Redux for persistence, we can save time by borrowing an existing of the game itself. model This particular happens to be friendly, local, and synchronous, but it’s easy to imagine moving to the far end of an HTTP request. Its behavior would remain the same in either case: given the current state of the and a request to reveal or flag a single cell, the will return a new state updated to reflect the consequences of the request. implementation MinesweeperAPI Game MinesweeperAPI Next, we’ll need to tell TypeScript about the “shape” of the . This consists of —the size of the board and how many mines are hidden on it—a , and several indices comprising the state of the board. The finished type declaration documents this nicely: Game Options moveCount This time with Redux We’ve got a game—we just need somewhere to put it. We’ll prepare Redux to store and update the state of the by mirroring the public in typed actions of our own: Game MinesweeperAPI Except for these look just like the action creators we would write in vanilla JavaScript. But by stating our assumptions up front, the TypeScript compiler can enforce the shape of these actions elsewhere in the app. If we try to create an action that isn’t declared in the , the program won’t compile. the type definitions Action union Playing the Game We’ll get even more benefit from static typing inside the store. One of the is the complexity of increasingly “deep” reducers, accessors, and state. By declaring their shape preemptively, the TypeScript compiler can warn us about typos, missing parameters, and broken references. challenges of scaling Redux To keep things simple, we’ll build the store around the existing type from the domain model. Even with this relatively flat data-structure, we’ll sleep easier at night with TypeScript’s assurance that the rest of the app is following the rules. Game Break it! Try accessing within the branch, and check out the resulting compiler error. action.options 'REVEAL_LOCATION' Building the Frontend Speaking of “check out”, the clock! Time’s tight, but we still have time for a bit of civic beautification. To get things going, let’s the Redux store to the component tree by wrapping a around our root element. This works exactly as in JavaScript: connect [Provider](https://github.com/reactjs/react-redux/blob/4c2670dc11cc067ef106f6c527e6e8b9d47f8af8/docs/api.md#provider-store) ReactDOM.render(<Provider store={store}><App /></Provider>,document.getElementById('root') as HTMLElement); Next, we’ll scaffold a root application component and it to the provided . [connect](https://github.com/reactjs/react-redux/blob/4c2670dc11cc067ef106f6c527e6e8b9d47f8af8/docs/api.md#connect) store TypeScript adds several new facets here. The and functions passed into each have their own type declarations, whose intersection represents the component’s own . When the dust settles, will receive the entire Redux plus the three available actions and a array to simplify rendering. In return for the added ceremony, we get type-safety all the way down: unknown actions, malformed props, and undefined references will now all trigger errors at compile time. mapStateToProps mapDispatchToProps connect Props <App /> Game grid Rendering a Cell is wired into the store but isn’t much to look at yet. To fix that, let’s create a component representing a single cell on the grid: <App /> Leaving CSS and rendering optimization as for a exercise (we’re on a schedule, here!) this looks nearly like it would in JavaScript. is the name of the game: once TypeScript understands the boundaries of the application, it can infer the correct types for most of the details inside. This won’t much matter to our little speed-run, but it will save much ceremony as the project scales up. future Inference The one thing the compiler won’t infer nicely are new data crossing the application boundary. When a cell is clicked, for instance, we need to tell what sorts of events an independent event handler is prepared to receive: TypeScript e: React.MouseEvent<HTMLButtonElement> The compiler can now verify that we’re handling the event correctly. If we pass on a or attach the handler to something other than a , we’ll be greeted with an error at compile time. KeyboardEvent <button /> Finishing the board We’re nearly there! We need two more things to get the game running inside the : a hook to create the initial game state, and a method to put the grid on the screen. <App /> [componentDidMount](https://reactjs.org/docs/react-component.html#componentdidmount) render CellComponent This is just JavaScript—with all the types declared upstream, TypeScript will infer the details the rest of the way down. Wrapping Up Pencils down. 14:59. Tack on a beautiful design, and there it is: statically-verified Minesweeper in just under 15 minutes. We’ve left plenty of details for other , but the patterns introduced here can carry over to projects of all sizes and shapes. TypeScript tutorials The finished game isn’t the prettiest thing. No tests, suboptimal rendering, and plenty of opportunity for the design team, but we’re finally to the part where TypeScript shines brightest. As the project evolves, all the assumptions embodied in our type declarations will be preserved for reference—and backed by a friendly warnings anytime something breaks the rules. Check out the ! finished project on Github
