ALAN LAVENDER @lavenderlens@qoto.org

...And drop it on my Netlify manual deploys area. I could just as well sync the project folder to a GitHub repo if I wanted to go serverless. My book site for The Frontend Cookbook is deployed this way. But drag and drop - what could be handier? Netlify also provides FREE OF CHARGE secure server certs through partnering with LetsEncrypt. The domain name for the app, choros.ie, is pointed to Netlify nameservers and configured with its https cert in this way.
>>

All my Node module projects are kept outside of Mac Documents or Desktop so they don't be forever getting backed up to iCloud with all their Node modules.

TO PUBLISH: I grab the /dist directory...
>>

The contents of the _redirects file.
>>

The folder structure of the /dist directory looks like this. The Vite bundler smooshes all my JS and CSS including Tailwind and custom styles into two tiny JS and CSS files in /assets. But I must manually add a _redirects file (no extension) to avoid 404s on my Netlify-hosted site. It's a Netlify-with-SPA thing. Top kudos to my colleague Stuart for figuring this out from the Netlify docs.
>>

Next, I stop my Vite dev server and run a build. The generated /dist folder will be the code that gets uploaded to go live.
>>

...And paste them into the hardcoded JavaScript array. VS Code automatically re-formats for me (if it didn't, that would have been a deal-breaker for this workflow!!).
>>

So after previewing on the Vite dev server, I just grab the songs from the JSON for the json-server...
>>

...And this is my production mode, where the data is copied over to a hardcoded JS array of songs.

I trialled a version of the app with a search functionality where users search a JSON file of all the songs and load up their own selection. This was the way it was envisaged from the start, with partial first line or partial title search functionality. Part of the use case for the app was because it was impossible to decide whether to index hardcopies on first line or title. And a double-entry cross-referenced system would be the only solution on paper, doubling the bulk of photocopies. But after the trial the choir decided they preferred the songs ready-loaded with no search and add function.
>>

This is the dev mode, hitting up an endpoint in the JSON on port 4000...
>>

Here's some of the JSX for my Songs component. This is the stateful part of the app where I can switch from my own dev mode to production.
>>

With the other songs for the night, the front end of the app should load like this on the dev server:
>>

But all being well the json-server will show a successful POST request.
>>

The Vite dev server can get a little grumpy at times.
>>

Trailing commas after the last item of the songs array must also be removed.
>>

My code replaces line returns with HTML <br> tags.
>>

There's the song in the app's JSON now.
>>

PDFs very often copy across with unusual line terminators. JSON is a very fussy format but that's partly what makes it so popular as a "glue" language format between different scripts or parts of a app. It's easy to remove them: they are highlighted in Visual Studio Code.
>>

There are fields for Song Title, Words, Usage, Key, Capo, and YouTube embed video link for learning new songs from the web. Mostly it's just Title and Words, but that enables a search on EITHER Title or first line in another version of the app. Handy.
>>

Next, fire up the React app, made in Vite, in development mode, also with a json-server loading the songs table JSON. Copy/paste new song into form in the app.
>>

Possibly of interest to those #React #JavaScript developers among you, here is today's workflow for updating a new song in my choir app. End-to-end 20 mins or less. Start by texting the song to myself from PDF supplied. It works from a photocopy too, using scan text OCR in Mac Notes. >> THREAD