mirror of
https://github.com/facundoolano/jorge.git
synced 2024-11-16 07:47:40 +01:00
outline + intro for serve command post
This commit is contained in:
parent
11e4e32db8
commit
af09593474
1 changed files with 46 additions and 0 deletions
46
docs/src/blog/a-site-server-with-live-reload.org
Normal file
46
docs/src/blog/a-site-server-with-live-reload.org
Normal file
|
@ -0,0 +1,46 @@
|
|||
---
|
||||
title: A site server with live reload
|
||||
date: 2024-03-05
|
||||
layout: post
|
||||
lang: en
|
||||
tags: [golang, project]
|
||||
draft: true
|
||||
---
|
||||
#+OPTIONS: toc:nil num:1
|
||||
#+LANGUAGE: en
|
||||
|
||||
** 1. Introduction
|
||||
|
||||
The core of the static site generator is the ~build~ command: take some input files, process them ---render templates, convert other markup formats into HTML--- and write the output for serving to the web. <This is where I started with ~jorge~, not only because it was the fundamental feature but because I needed to see the org-mode parsing output as early as possible to know whether I could reasonably expect this project to ultimately replace my Jekyll + org-export setup.
|
||||
|
||||
Although you could say that I had a working static site generator as soon I had the ~build~ command, for it to be minimally useful I needed some facility to preview a site while working on it: a ~serve~ command. It could be as simple as running local file server of the ~build~ output files, but ideally I would make it watch for changes and live reload the browser tabs looking at them.
|
||||
|
||||
I was aiming for more than the basics here because ~serve~ was the only non-trivial command I had planned for: the one with the most potential to learn other Go features ---and the most fun. For similar reasons I wanted to tackle it as early as possible: since it wasn't immediately obvious how I would implement it, it was here where unknown-unknowns and blockers were most likely to come up.
|
||||
I knew it was a feasible feature because other generators have it, but I didn't want to just copy whatever Hugo or gojekyll were doing, I wanted to figure it out for myself.
|
||||
|
||||
The beauty of the ~serve~ command was that I could start with the most naive implementation and iterate towards the ideal one, keeping a usable command at every step. With ~build~ and ~serve~ out of the way, I'd be almost done with the project, the rest being nice to have features and UX improvements.
|
||||
|
||||
** 2. Context
|
||||
|
||||
** 3. Implementation
|
||||
|
||||
*** A basic file server
|
||||
|
||||
- basic fs server implementaion
|
||||
- improve for directory and html handling
|
||||
|
||||
*** Watching for changes
|
||||
- fsnotify to trigger builds
|
||||
- optimization: ln static files
|
||||
- optimization: worker pool
|
||||
|
||||
*** Live reload
|
||||
|
||||
- naive implementation
|
||||
- event broker
|
||||
- is this name right?
|
||||
|
||||
*** Refinements
|
||||
- don't stop on errors
|
||||
- ignore chmod and temp file events
|
||||
- delay to prevent bursts
|
Loading…
Reference in a new issue