Publish your reading list.

By the end of this part your reading list will be online, at a link you can open on your phone and send to a friend.

You start with the tested app and the checkpoint from Part 8. Your agent prepares the files, and you do the upload yourself on Netlify’s website. You’ll need a Netlify account; check its current plan and limits when you sign up. You don’t need GitHub or an address of your own.

1. Build the files to publish

So far your app has come from the development server on your own computer, at an address beginning 127.0.0.1. That server is made for working on an app: it rebuilds the page the moment the agent changes something and gives extra help with errors. It runs only while your computer does, and only your computer can reach it.

To publish, you swap it for a host that is always on and that anyone can reach. You don’t give that host your working project, though. The project is arranged for editing, spread over many files, and depends on tools installed on your computer. A production build turns it into a small set of compact files that a browser can use directly, and puts them in a folder called dist. You and your agent edit the project; dist is made from it, and every new build replaces it.

The prompt asks the agent to run all your tests, make the build, and show you what is in dist and what each file would make public. It then starts a preview of the built files so that you can try them, and stops without publishing anything.

Read docs/brief.md and docs/epics/06-publish.md. Check the previous epic for unresolved failures before preparing a release. Run the unit tests, the browser tests and npm run build. Verify the generated dist folder contains index.html, style-guide.html, mockServiceWorker.js and their referenced assets. Show me what is in the dist folder and tell me what each file would make public. Start the production preview with npm run preview and check it in a browser if tools are available. Give me the preview URL and the exact dist folder to upload. Record performed checks and anything unverified. Do not upload or deploy; I will do the manual publishing step.

When the agent stops, open the preview address it gives you and add, edit and refresh a book. The preview delivers the files in dist, so you are trying exactly what will be uploaded, though it is still on your computer. It starts with an empty list, because the preview has a different address from the one you’ve been using, and a different address has its own storage.

Then look at what the agent listed in dist. Two things are worth knowing.

mockServiceWorker.js belongs to the stand-in server. It is the piece that lets your browser show the app’s requests in the Network tab. It must be uploaded with everything else, so leave it where it is. You don’t need to know more about it than that.

There are two pages, not one. Beside index.html is style-guide.html, the page you made in Part 4. Nothing in the app links to it, but once the folder is online, anyone who knows the address can open it. Publishing it is harmless and mildly useful, since you can then open your style guide from any device. If you’d rather it stayed private, tell your agent to leave style-guide.html and the files only it uses out of the folder you upload. Either answer is fine. Deciding what becomes public, and not finding out afterwards, is the habit worth keeping.

If a test fails or the build stops with an error, don’t publish. Ask the agent what failed and whether the app or the test is wrong, as in Part 8, and run the prompt again once it is fixed.

2. Upload your app

Notice where the agent stopped: it prepared the folder and went no further. The prompt told it to, and so does your root file, whose hard limits begin with “Never publish, push or deploy unless the person asks.” The rule is written down so that you don’t have to remember to say it each time. Publishing is the moment your work becomes public, so in this project it is always your decision, and you do the upload yourself.

The host we’ll use is Netlify, and what it offers for a folder like yours is called static hosting: it stores the files and delivers them, unchanged, to whoever asks. It runs none of your code. That is enough for this app, because the stand-in server travels inside those files and runs in each visitor’s browser, as it has in yours all along. An app with a real server needs more: somewhere to run the server program and a database behind it, which is a different kind of hosting with its own costs.

1. Sign in to your Netlify account and open Netlify Drop.
2. Drag the dist folder onto the page. Choose the folder the agent named, the one that contains index.html, and not the whole project or the ZIP you downloaded in Part 1. If you can’t find it, ask the agent to open the folder for you or to give you its full path.
3. Wait for the upload to finish, then open the site address Netlify gives you. It is a name Netlify chose, ending in netlify.app.

A site published this way is normally open to anyone who has the address. If yours asks visitors for a password, look at the site’s access settings in Netlify.

Netlify’s own instructions for uploading a folder show the current screens if anything looks different from these steps.

Uploading dist is not a backup of your project. The files you edit stay on your computer, and only the built copy is online.

3. Check the published version

A successful upload doesn’t show that the app works there, so check it as you checked every stage. At your new address, add a book, edit it, refresh and see that it is still there. Try a filter, then remove the book and undo. Open the link on your phone and look at the layout.

Your list starts empty there, and that is expected. The published site has a different address from the one on your computer, so your browser starts a separate stand-in server for it, with its own empty store. The books you added while building haven’t moved and haven’t been lost; they are still at the local address. The Network tab works on the published site too, and shows the same requests and status codes you watched in Part 6.

Your friends will each see their own empty list, and never yours. Everyone who opens your link gets the client and their own stand-in server, running in their own browser. Part 5 explained why: a real server is one program on one computer that every visitor’s client talks to, which is what lets people share data, and also the point at which accounts and security start to matter. Yours has no such computer, so nothing is shared.

Now tell your agent what happened, so that the project’s records are true: “I published the app at [your address]. I checked adding, editing, refreshing, a filter, remove and undo, and the phone layout, and they worked. Record this in docs/epics/06-publish.md and docs/progress.md, marking these as my own checks.” Then ask for a checkpoint in your usual sentence: “Checkpoint: Publish the reading list”. Your handbook runs the tests first, as it has since Part 8.

4. Update your published app later

Changes on your computer don’t reach the published site by themselves. When you change the app, ask the agent to run the tests and make a new build, then open your site in Netlify, go to its Deploys page and drag the new dist folder onto it. The address stays the same. Check the result there, as you did in step 3. You’ll do exactly this in Part 10.

You now have a working app at a link you can share, and you made every decision in it. One thing is left. Nearly everything so far was built from prompts we gave you. Next, in Part 10, you’ll add a feature nobody gave you a prompt for, from one of your own “Later ideas”, and publish it to this same link.

FAQ

Further reading

• Get started with domainsNetlify

  If you want your own address instead of the one Netlify assigns, this page asks a few questions and points you to the right steps.

• What is a domain name?MDN

  How addresses like example.com work, who sells them and what you are paying for.