Study Journal 06-08-2024

Where I’m at

• Personal study: Yesterday was a good day where it started to make more sense what Runes were actually doing. Also I learnt about Mermaid Charts which make flowcharts pretty easy and declarative.
• Knowledge Base: Considering going with Kit-Docs. I’ve used them before and they are pretty straightforward.
• Personal Crypto Project: Feeling kind of anxious. I feel confident that I can definitely create the damn thing but marketing? Either I spent a shit tonne of money on marketing and leave it someone else, or try and do it myself? I guess the only thing is that I can start to market it full-time after I create it, so I only have to focus on one thing at a time.

What I learnt

Svelte Runes: To use $derived, or to not $derived.

TL;DR — Compute using functions, unless it’s big and scary then use $derived

• The $derived rune is used to complete computations on signals ($state runes)
• What’s forgotten here is that also functions can also perform computations on signals as well
• The difference being that runes are quite computationally heavy in comparison to a function
  • Example: Suppose you had a growable network of nodes component that depended on 5 source signals.
  • If you computed using a function, and then returned that value to 1 node, you’d have created 5 connections. If you had 5 nodes, you’d have created 25 connections.
  • If you computed using a $derived rune, then the computation is cached until the signals changed. If you had 1 node, you’d have 6 connections (5 for source, and 1 for the node connection), but if you had 5 nodes you’d have 10 connections (5 for source, and 5 for the nodes).
  • Expressed mathematically — where s = sources, c = connections, and n = nodes:
    • Computation by function: s * n = c
    • Computation by derived: s + n = c
• The long and short of $derived usually comes down to complexity, and computation size. If it’s big and hairy, used a $derived rune. Otherwise, in most cases, simply use a function to return computed values.

Svelte Runes: Don’t use $effect, when you can use $derived instead.

• It took me a while to get my head around the video and the content. But bear with me with an example:
  • The Rune Restaurant
  • Imagine a restaurant that has two shifts: Day shift and night shift.
  • They have servers that input orders into the till (These are $state values), and cooks that look at a order screen in the kitchen (These are $derived values).
  • Imagine that the night shift is staffed entirely by vampires (these are $effect values).
    • The vampires are really good at cleaning up, or doing secondary tasks for the next day.
    • But they can’t be used to input orders into the till, or to have them cook food. Sure you might be able to, but it’s clearly unadvisable in almost all cases.
    • These vampires also act well as a stop gap measure in ensuring tasks are done correctly, double checking things are in order before they are executed.

Adapting our SOLID heuristic from yesterday:

When we’re building a Svelte 5 reactive component, think of the restaurant:

$state: The till

• Where orders are placed, and basic information stored
• Directly modifiable and observable
• Changes here trigger updates in the kitchen

Checklist:

• What calculations or transformations does your component need?
• What values depend on your $state variables?

Example:

• Order totals, kitchen queue, ingredient usage calculations

$derived: The kitchen display

• Shows information based on till inputs
• Automatically updates when till information changes
• Doesn’t modify till information directly

Checklist:

• What calculations or transformations does your component need?
• What values depend on your $state variables?

Example:

• Order totals, kitchen queue, ingredient usage calculations

$effect: The vampire staff

• Works after hours, when the main restaurant is closed
• Handles cleanup, analytics, and other behind-the-scenes work
• Useful as a guard for validating tasks, items, etc
• Won’t use either the till, or look at the screen directly.

Checklist:

• What side effects or external interactions does your component need?
• What tasks should happen after state updates but before the next render?
• What “stop gap” measures or final checks are needed?

Example:

• Cleaning up, inventory checks, preparing for the next day, double-checking order accuracy.

Remember! While vampires are great at night tasks, don’t ask them to operate the till, or cook during the day!

$props and $bindable: Data-links of the restaurant

Props: Till to Kitchen Display Screen

• Data flows one-way: from till to display screen
• Kitchen staff can see orders but can’t modify them through the screen
• Represents read-only data passed from parent to child component
• Example: let { orderDetails } = $props();

Bindables: Uber Eats Tablet:

• Two-way communication: restaurant ↔ Uber Eats ↔ customer
• Can display menu (read data) and update order statuses (write data)
• Represents two-way data binding between parent and child components
• Example: let { orderStatus = $bindable('pending') } = $props();

What I did

• Continued with learning about Svelte Runes because that’s the hardest thing about Svelte at the moment that I struggle with understanding properly.

  I moved onto to part 2 of the series I watched yesterday. The next part is about using the $derived rune.

  That down, I then moved onto the next part in the series. Which is about the $effect rune.

• I’ve finished my study on Svelte Runes for now. We’ll come back to that in due course.

• Worked through a bunch of shit on my personal crypto project, it’s a slog because so little of the Web3 libraries have specific Svelte implementation. As part of building, I wanted to also do some of this work because it would help both the community, and myself at the same time.

  If I end up creating a large amount of components, then I might consider creating a library out of it.

  Seeing runes working nicely after going over the study today was nice to see because it is starting to integrate my study with my own projects.