Merge branch 'main' into uwu

This commit is contained in:
James Fenn
2023-09-17 15:34:45 -04:00
10 changed files with 110 additions and 66 deletions

View File

@@ -23,38 +23,12 @@ Another example is users with limited mobility who utilize specialty hardware, s
Something to keep in mind is that these disabilities may not be permanent. For instance, if you fall and break your arm, you may be only using one arm while healing. Likewise, there are situational impairments as well. If you're holding a cup of coffee in one hand, you'll only be using the other for device usage. Here's a chart that outlines a few more of these examples:
<table>
<tr>
<th></th>
<th scope="col">Permanent</th>
<th scope="col">Temporary</th>
<th scope="col">Situational</th>
</tr>
<tr>
<th scope="row">Touch</th>
<td><img src="./one_arm.png" style="height: 200px"/><br/>One arm</td>
<td><img src="./arm_injury.png" style="height: 200px"/><br/>Arm injury</td>
<td><img src="./new_parent.png" style="height: 200px"/><br/>New parent</td>
</tr>
<tr>
<th scope="row">See</th>
<td><img src="./blind.png" style="height: 200px"/><br/>Blind</td>
<td><img src="./cataract.png" style="height: 200px"/><br/>Cataract</td>
<td><img src="./distracted_driver.png" style="height: 200px"/><br/>Distracted driver</td>
</tr>
<tr>
<th scope="row">Hear</th>
<td><img src="./deaf.png" style="height: 200px"/><br/>Deaf</td>
<td><img src="./ear_infection.png" style="height: 200px"/><br/>Ear infection</td>
<td><img src="./bartender.png" style="height: 200px"/><br/>Bartender</td>
</tr>
<tr>
<th scope="row">Speak</th>
<td><img src="./non_verbal.png" style="height: 200px"/><br/>Non-verbal</td>
<td><img src="./laryngitis.png" style="height: 200px"/><br/>Laryngitis</td>
<td><img src="./heavy_accent.png" style="height: 200px"/><br/>Heavy accent</td>
</tr>
</table>
| | Permanent | Temporary | Situational |
|-------|-----------|-----------|-------------|
| Touch | <img height="200" src="./one_arm.png" alt=""><br> One arm | <img height="200" src="./arm_injury.png" alt=""><br> Arm injury | <img height="200" src="./new_parent.png" alt=""><br> New parent |
| See | <img height="200" src="./blind.png" alt=""><br> Blind | <img height="200" src="./cataract.png" alt=""><br> Cataract | <img height="200" src="./distracted_driver.png" alt=""><br> Distracted driver |
| Hear | <img height="200" src="./deaf.png" alt=""><br> Deaf | <img height="200" src="./ear_infection.png" alt=""><br> Ear infection | <img height="200" src="./bartender.png" alt=""><br> Bartender |
| Speak | <img height="200" src="./non_verbal.png" alt=""><br> Non-verbal | <img height="200" src="./laryngitis.png" alt=""><br> Laryngitis | <img height="200" src="./heavy_accent.png" alt=""><br> Heavy accent |
> Microsoft originally created this chart as part of their [Inclusive Toolkit](https://download.microsoft.com/download/b/0/d/b0d4bf87-09ce-4417-8f28-d60703d672ed/inclusive_toolkit_manual_final.pdf) manual

View File

@@ -3,6 +3,7 @@
title: "Minecraft Data Pack Programming: Introduction",
description: "Learn the beginnings of data pack development in Minecraft - using commands and functions to add custom behavior from scratch!",
published: '2022-06-14T21:12:03.284Z',
edited: '2023-09-12',
authors: ['fennifith'],
tags: ["minecraft"],
attached: [],
@@ -93,7 +94,9 @@ The `"pack_format": 10` in this file corresponds to Minecraft 1.19; typically, t
| Minecraft Version | `"pack_format"` value |
|-------------------|-----------------------|
| 1.19 | `"pack_format": 10` |
| 1.20-1.20.1 | `"pack_format": 15` |
| 1.19.4 | `"pack_format": 12` |
| 1.19-1.19.3 | `"pack_format": 10` |
| 1.18.2 | `"pack_format": 9` |
| 1.18-1.18.1 | `"pack_format": 8` |
| 1.17-1.17.1 | `"pack_format": 7` |
@@ -122,15 +125,13 @@ Note that, while a preceding `/` is needed to type these commands into the text
We should now have our data pack organized as follows:
```shell
1-introduction/
pack.mcmeta
data/
fennifith/
functions/
animals/
spawn.mcfunction
```
<!-- filetree:start -->
- `1-introduction/`
- `pack.mcmeta`
- `data/`
- `fennifith/functions/animals/`
- `spawn.mcfunction`
<!-- filetree:end -->
## Installing & testing the data pack
@@ -189,20 +190,16 @@ In order to run a function automatically, Minecraft provides two built-in [funct
We'll start with `load` &mdash; for which we'll need to create two new files in our folder structure! Below, I'm creating a new `load.mcfunction` next to our previous function, and a `minecraft/tags/functions/load.json` file for the `load` tag.
```shell
1-introduction/
pack.mcmeta
data/
minecraft/
tags/
functions/
load.json
fennifith/
functions/
animals/
load.mcfunction
spawn.mcfunction
```
<!-- filetree:start -->
- `1-introduction/`
- `pack.mcmeta`
- `data/`
- `minecraft/tags/functions/`
- `load.json`
- `fennifith/functions/animals/`
- `load.mcfunction`
- `spawn.mcfunction`
<!-- filetree:end -->
Note that, while I'm using the `fennifith/` namespace for my functions, the tag file lives under the `minecraft/` namespace. This helps to keep some data isolated from the rest of the game &mdash; any files in the `minecraft/` folder are *modifying Minecraft's functionality,* while anything in a different namespace is creating something that belongs to my data pack.

View File

@@ -24,8 +24,9 @@ To showcase this, lets walk through some of these frameworks and compare and
While web frameworks are the hot new jazz - its not like we couldnt make web applications before them. With the advent of W3C standardized web components (without Lit), doing so today is better than its ever been.
Here are some pros and cons of Vanilla JavaScript web components:
<table class="wp-block-table"> <tbody> <tr> <th> Pros </th> <th> Cons </th> </tr> <tr> <td> <ul> <li><span>No framework knowledge required</span></li> <li><span>Less reliance on framework</span></li> </ul> <ul> <li><span>Maintenance</span></li> <li><span>Bugs</span></li> <li><span>Security issues</span></li> </ul> <ul> <li><span>Smaller “hello world” size</span></li> <li><span>More control over render behavior</span></li> </ul> </td> <td> <ul> <li><span>Re-rendering un-needed elements is slow</span></li> <li><span>Handling event passing is tricky</span></li> <li><span>Creating elements can be overly verbose</span></li> <li><span>Binding to props requires element query</span></li> <li><span>Youll end up building Lit, anyway</span></li> </ul> </td> </tr> </tbody> </table>
| Pros | Cons |
|------------|------------|
| <ul><li>No framework knowledge required</li><li>Less reliance on framework</li></ul><ul><li>Maintenance</li><li>Bugs</li><li>Security issues</li></ul><ul><li>Smaller “hello world” size</li><li>More control over render behavior</li></ul> | <ul><li>Re-rendering un-needed elements is slow</li><li>Handling event passing is tricky</li><li>Creating elements can be overly verbose</li><li>Binding to props requires element query</li><li>Youll end up building Lit, anyway</li></ul> |
To the vanilla way of doing things credit, theres a bit of catharsis knowing that youre relying on a smaller pool of upstream resources. Theres also a lessened likelihood of some bad push to NPM from someone on the Lit team breaking your build.
@@ -170,7 +171,9 @@ You could work on fixing these, but ultimately, youve created a basis of what
With the downsides (and upsides) of vanilla web components in mind, lets compare the pros and cons of what building components using Lit looks like:
<table class="wp-block-table"> <tbody> <tr> <th> Pros </th> <th> Cons </th> </tr> <tr> <td> <ul> <li><span>Faster re-renders* that are automatically handled</span></li> <li><span>More consolidated UI/logic</span></li> <li><span>More advanced tools after mastery</span></li> <li><span>Smaller footprint than other frameworks</span></li> </ul> </td> <td> <ul> <li><span>Framework knowledge required</span></li> <li><span>Future breaking changes</span></li> <li><span>Not as widely known/used as other frameworks (Vue, React, Angular)</span></li> </ul> <p><span></span></p> </td> </tr> </tbody> </table>
| Pros | Cons |
|------------|------------|
| <ul><li>Faster re-renders* that are automatically handled</li><li>More consolidated UI/logic</li><li>More advanced tools after mastery</li><li>Smaller footprint than other frameworks</li></ul> | <ul><li>Framework knowledge required</li><li>Future breaking changes</li><li>Not as widely known/used as other frameworks (Vue, React, Angular)</li></ul> |
While there is some overlap between this list of pros and cons and the one for avoiding Lit in favor of home-growing, theres a few other items here.

View File

@@ -71,7 +71,7 @@ There are two primary differences from the vanilla JavaScript example. First, we
That said, Lit components fully support the same lifecycle methods as a vanilla custom elements.
The second, easier-to-miss change from the vanilla JavaScript component to the Lit implementation, is that when we set our HTML, we dont simply use a basic template literal (`<p>test</p>`): we pass the function `html` to the template literal (`html\`<p>test</p>\``).
The second, easier-to-miss change from the vanilla JavaScript component to the Lit implementation, is that when we set our HTML, we dont simply use a basic template literal (`<p>test</p>`): we pass the function `html` to the template literal (``html`<p>test</p>`;``).
This leverages [a somewhat infrequently used feature of template literals called tagged templates](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates). Tagged templates allow a template literal to be passed to a function. This function can then transform the output based on the string input and expected interpolated placeholders.