add a tagging system to the website
This commit is contained in:
parent
701da6bc4b
commit
e1b6578b2a
97 changed files with 1025 additions and 979 deletions
|
|
@ -1,4 +1,6 @@
|
|||
%% title = "not quite buildless"
|
||||
%% id = "b?01J7C1KBZ58BR21AVFA1PMWV68"
|
||||
title = "not quite buildless"
|
||||
tags = ["all", "programming", "treehouse"]
|
||||
|
||||
% id = "01J7BYKQGYPF50050K67N2MP1G"
|
||||
- ...buildsome?
|
||||
|
|
@ -56,7 +58,7 @@ enjoy!
|
|||
% id = "01J7BYKQGY7QEAN677Q9AT4T0V"
|
||||
- I'll put _probably_ the most interesting bit right at the start.
|
||||
the treehouse is _not quite_ buildless.
|
||||
|
||||
|
||||
% id = "01J7BYKQGYRV6TKEACZ0DXNDG4"
|
||||
- one might even call it... buildsome?
|
||||
I mean, it's not quite buildful, and definitely not buildless...?
|
||||
|
|
@ -147,7 +149,7 @@ enjoy!
|
|||
|
||||
% id = "01J7BYKQGY0PR13G71PK163976"
|
||||
- if I _wanted_ to implement incremental builds, I feel like the dependency tracking would get pretty hellish pretty quickly.
|
||||
|
||||
|
||||
% id = "01J7BYKQGY75XN1HBVZ110D16P"
|
||||
- say a `.tree` file uses the `include_static` template directive to include some file into itself.
|
||||
now in addition to compiling the `.tree` file when it changes, I'd also need to recompile the `.tree` file when that `include`d`_static` file changes too---and that sort of dependency tracking is ripe for bugs as the codebase grows more complex!
|
||||
|
|
@ -223,7 +225,7 @@ enjoy!
|
|||
|
||||
% id = "01J7EMBKN42WH0BKXKDQ020F8M"
|
||||
- you can also provide source maps to transfer optimal minified sources by default, and let your browser's DevTools display your original sources to the user upon their request.
|
||||
|
||||
|
||||
% id = "01J7EMJYX91P3RE3PEBM2M3MR1"
|
||||
- the important part is that having _some_ form of readable sources _right on your page_ is really nice!
|
||||
|
||||
|
|
@ -237,7 +239,7 @@ enjoy!
|
|||
- the reason is that I don't want to waste time testing my website separately on release mode, so having it behave differently in subtle ways means more bugs!
|
||||
|
||||
% id = "01J7BYKQGY6KJ6ZZX4EREEAB79"
|
||||
- there are only two parts of the treehouse that behaves differently between debug and release mode.
|
||||
- there are only two parts of the treehouse that behaves differently between debug and release mode.
|
||||
|
||||
% id = "01J7BYKQGYB4G0J7TZQCF4X7W6"
|
||||
- generation speed, and...
|
||||
|
|
@ -316,7 +318,7 @@ enjoy!
|
|||
|
||||
async fn back_up() -> String {
|
||||
"".into()
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
% id = "01J7BYKQGYDY8E84BEM5V7MMGB"
|
||||
|
|
@ -333,7 +335,7 @@ enjoy!
|
|||
|
||||
% id = "01J7BYKQGYVS4CZGVC4ZHGJ7KF"
|
||||
- also, `tower-livereload` also has a couple disadvantages compared to the solution I've shown here.
|
||||
|
||||
|
||||
% id = "01J7BYKQGY3P95RM10ZZGRP2Y3"
|
||||
- it's slow, because it only polls the server's `/back-up` endpoint every second, which increases reload latency.
|
||||
I've bumped that up to polling every 100ms in my script, because I don't like slow.
|
||||
|
|
@ -377,7 +379,7 @@ enjoy!
|
|||
|
||||
% id = "01J7BYKQGYM9HD00VY2BVEZPZ0"
|
||||
- _customized built-in elements_, which extend _any_ built-in element.
|
||||
these are applied using the `is=""` attribute on a base built-in element, like `<li is="your-element"></li>`.
|
||||
these are applied using the `is=""` attribute on a base built-in element, like `<li is="your-element"></li>`.
|
||||
|
||||
% id = "01J7BYKQGY90D6C0KF9CFSMF1A"
|
||||
- unfortunately customized built-in elements are practically useless, because Safari doesn't implement them, [and doesn't even plan to do so](https://github.com/WICG/webcomponents/issues/509#issuecomment-222860736)...
|
||||
|
|
@ -408,7 +410,7 @@ enjoy!
|
|||
```
|
||||
|
||||
and off we go!
|
||||
|
||||
|
||||
% id = "01J7BYKQGY6YE329DB9PMY8KNW"
|
||||
- I've found a couple useful idioms for working with custom elements.
|
||||
|
||||
|
|
@ -476,7 +478,7 @@ enjoy!
|
|||
|
||||
% id = "01J7BYKQGYYBY9RDFJG8BP61QP"
|
||||
- and that's it! the actual value of the `?cache` parameter is never interpreted by anyone, anyhow.
|
||||
it's only there so that whenever something _does_ change, we change the URL, and the browser thinks that "hey, that's a different asset! gotta download it."
|
||||
it's only there so that whenever something _does_ change, we change the URL, and the browser thinks that "hey, that's a different asset! gotta download it."
|
||||
|
||||
that way, the browser only ever downloads files that changed since your last visit.
|
||||
|
||||
|
|
@ -540,7 +542,7 @@ enjoy!
|
|||
|
||||
% id = "01J7C16RSZ7NHE5N3KV57NGWT0"
|
||||
- okay cool we're getting somewhere,
|
||||
|
||||
|
||||
% id = "01J7C16RSZQPMABF0SBDH1RHA7"
|
||||
- "and then we could even cache that import map with a `?cache` parameter too---"
|
||||
|
||||
|
|
@ -589,10 +591,10 @@ enjoy!
|
|||
|
||||
% id = "01J7BYKQGYMMCAKQX9S8JCTJW6"
|
||||
- as time went on though, I discovered another light markup language: [_Djot_](https://djot.net/), made by the same person who made Markdown, with _lots_ of lessons learned from his previous attempt.
|
||||
|
||||
|
||||
% id = "01J7BYKQGYQQP0YSWA1TEHRB9S"
|
||||
- I initially didn't wanna go through with it, because "_sigh_ am I really gonna have to rewrite my entire content to use Djot?"
|
||||
|
||||
|
||||
% id = "01J7BYKQGYSKJNTB7BGKTED4S0"
|
||||
+ but then I did it anyways, because life's too short to have to deal with poorly designed markup languages :hat_smug:
|
||||
|
||||
|
|
@ -638,7 +640,7 @@ enjoy!
|
|||
|
||||
% id = "01J7C16RSZAECM1G9CD57WX1M6"
|
||||
- I am pushing into a string, that literally cannot fail! (other than with an OOM, but that's a panic)
|
||||
|
||||
|
||||
% id = "01J7BYKQGYJMRC7DY7SNMAQ538"
|
||||
- the HTML generation code got cleaner, because the crate I'm using---[`jotdown`](https://lib.rs/crates/jotdown)---does not use a callback for filling in broken links.
|
||||
a pattern that's best known under the moniker "yeah, don't do that" in the Rust world.
|
||||
|
|
@ -676,14 +678,14 @@ enjoy!
|
|||
|
||||
% id = "01J7BYKQGYV3H2WX6VVSR9EFEF"
|
||||
- what's funny is that it dies dropping a `rustc-ice-YYYY-MM-DDTHH_MM_SS-NNNNN.txt` file into your current working directory, and combined with `cargo-watch` this has the super funny effect of generating tens of those files in the treehouse repo.
|
||||
|
||||
|
||||
% id = "01J7C16RT0H84KPGJMBK1QT84E"
|
||||
- I have forgotten to remove these before checking in at least once before.
|
||||
I don't think I ever ended up pushing that commit though, so I can't show you... [but you can see the ICE I have stored in my local Git history here](/static/text/rustc-ice-2024-07-20T21_00_23-69819.txt).
|
||||
|
||||
% id = "01J7C16RT0R80J7KN516B06Q05"
|
||||
- an annoying side effect is that to fix this, I have to `^C` out of `cargo-watch`, run `cargo clean`, run `cargo-watch` again, and wait until the whole project compiles.
|
||||
|
||||
|
||||
% id = "01J7C16RT0XX4PZYRXAAV2M7P9"
|
||||
- at least it's a debug build...
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue