It may be formatted differently depending on your browser and extensions, and the IDs will differ:įirst, we create variables with a few restaurant names, because we'll use them several times. You should see the following JSON data, including a few default restaurants that were created when your API key was created. ![]() Next, go to in a browser, filling in your API key in place of YOUR-API-KEY. Copy it and save it someplace safe-you won't be able to get back to it again. ![]() You'll be given a new API key that is a random sequence of letters and numbers. This will allow you to access your own personal data on the server, so you can edit it without seeing or modifying others' data. Rather than using username-and-password authentication as we might do for a real system, for simplicity we'll just use an API key instead. Let's take a look at that backend and see how we can load our restaurant data from it. This exercise will focus exclusively on our frontend codebase, so we won't be building the corresponding backend we'll use one that has already been built. We'll do all our work from this feature on a branch. This ensures that all the layers work together, and it provides a framework for adding in future features. The point of a vertical slice is to get something built out that touches all the layers of your application. It also minimizes other work: we aren't building authentication now, and we aren't handling restaurant loading edge cases yet in this story. It touches all layers of our code: it has a user interface aspect (the list screen), a data layer aspect (where the restaurants are loaded and stored), and an API client aspect (the HTTP request to load the restaurants). We chose this story as our first feature story because it allows us to build out a vertical slice of our application. ![]() Our next story in Trello is the first one that involves building an application feature: "List Restaurants". ![]() In the last chapter we made it through a number of stories in Trello, each involving application setup. We'll also see the principle of "write the code you wish you had" in action. We'll follow the practice of outside-in test driven development: write a failing end-to-end test, watch it fail, then build out the functionality with unit tests using multiple inner red-green-refactor cycles. In this chapter we'll build our first application feature.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |