DEV Community: Pere Sola

How to connect two Windows computers with a wireless LAN

Pere Sola — Sat, 09 Nov 2024 12:15:05 +0000

Change profile:

Before:

After:

Before:

After:

All networks settings:

Before:

After:

Install Simple Analytics in an Astro js project

Pere Sola — Sat, 02 Nov 2024 17:23:31 +0000

There is an official package for that from the folks at Simple Analytics.
Just follow the instructions and you should be good to go. It worked flawlessly for me.
There is a bunch of props you can pass to it if you need configuration, you can find the docs about them here.
Add the domain to your Simple Analytics dashboard. The technology detected for me was HTML. After the code was deployed, it automatically detected that the script was there and it started working. Pretty cool!

Steps to fix package security vulnerabilities in your JS project

Pere Sola — Fri, 25 Oct 2024 16:19:12 +0000

Github sends you regular alerts when security vulnerabilities are detected among your installed packages or its dependencies. I used to try to let the dependabot fix them for me. However, half the time I was not able to merge the PR that had been generated for me. As a result, the violations were left unadressed, which is not good. In my case I use pnpm, I guess it is the same with npm.

I came across this article by Niraj Chauhan's today and it got me into how to solve them using the terminal.

Steps:

You get the dependabot alert from Github:

I know, the package name in the screenshot above doesn't match the rest of the article. But this is about the steps, you get the point.
Navigate to the project in your machine and run pnpm audit. You should see details about the vulnerabilities:

In the path section you should see what is causing this. In my case, it seems to be "nested dependencies" (dependencies of dependencies).
You can run pnpm why NAME_OF_THE_PACKAGE to confirm the above. In my case, I get this when running it on my first vulnerability: pnpm why netmask

You can try running pnpm audit fix but it never works for me.
Open your package.json and update the package version that is causing this - in my case mailgun-js. You can run pnpm view NAME_OF_THE_PACKAGE versions to see all the versions or pnpm info NAME_PACKAGE version to know the latest stable version.

If it is different, edit your package.json file with the version you need and run pnpm i again. After that you run pnpm audit again to confirm that the vulnerability is gone. If it is still there, start again or continue reading.

In my case, the latest stable version is the one I have installed, so I need to take another approach.
We can force pnpm to install a certain version of a nested dependency. The pnpm docs are here and you do it like so in your package.json file:

I got an error about the version I was trying to override, so I wrote the latest one in my package.json file:

Run pnpm i and happy days, the vulnerability for that package is no longer there.

Edit 25/10: according to this Stackoverflow thread, both Github dependabot and pnpm audit feed from the same database, so you are not missing on vulnerabilities byfixing things this way rather than the dependabot workflow. Also there is this blog post.

[WIP] ChatGPT API for Web Developers

Pere Sola — Sun, 23 Jun 2024 17:03:05 +0000

This post are the notes from FrontendMaster's course by Maximiliano Firtman.

A tour of web capabilities

Pere Sola — Wed, 03 Apr 2024 21:34:11 +0000

This post compiles notes from Max Firtman's course in Frontendmasters.

What is a capability? The ability of a web browser to perform an action using typically a built-in API. Compatibility can be an issue, of course. So some of the capabilities may not be available in some browsers.
Maturity of the capabilities: green (mature), light-green (may not be available in every browse. Normally chromium-based browsers vs Firefox/Safari), yellow (not mature and only available in some browsers), red (you can't use them and may be added in the long term).
Resources to check the capabilities: MDN, caniuse.com, web.dev, webkit.org/blog (specifically for Safari), chromestatus.com, web.dev/baseline (multivendor, define a list of stable capabilities, stable version for the web, one list per year starting in 2022).
Core capabilities NOT covered in this course: fetch, web workers (for threading), WebAssembly, WebSocket, WebRTC, WebPerformance APIs, Network information (see course here), Device memory, WebOTP (one-time password), Web Crypto (cryptography), storage (another course), Web Components, CSS, 2D Canvas, WebGL, Pointer Lock (for gaming), screen capture, PWA (course), page visibility, background sync, background fetch, web push, and notifications, media session (all these in the course), Web Authentication, passkeys, credential management, (all these in the course).
Permissions: some are harmless, others have a privacy risk or have a cost. If there is a cost or risk some browsers may limit it: user engagement requirements or permission dialog to the user. Most will require HTTPS. Some capabilities will need the user interaction to be enabled (aka you can't trigger it on page load). Permissions are granted on an origin base (domain). If the user denies permission, the API won't be able to ask again, manual re-enablement is required. Permission may have no time limit or it may be limited by time or session or usage. They are enabled for the main navigation (the HTML document that was loaded) - it won't be available for iframes. If you want to turn a capability off: permission policy spec, it's an HTTP header (Permissions-Policy), for an iframe it's an HTML attribute.

Capabilities

Permissions API

1. Permissions API.

MDN Docs here

Sensors, Geolocation, and Input Devices

Sensors on mobile devices: accelerometer (3 axis - x, z, y), gyroscope (turning the phone - alpha, beta, gamma), magnetometer (compass), proximity (to the user), light sensor.

2. Two ways to consume them on the web: old APIs (global DOM APIs, that is how you need to do it in iPhones and iPads. It only supports magnetometer, gyroscope, and accelerometer. Done with event listeners. i.e. `devicemotion` and `deviceorientation` (MDN docs here) and here. They need user permission), Sensor API (not yet in Safari nor Firefox, see MDN).

3. Geolocation API (one of the first capabilities on the web).

Google, Apple, etc. know your location because of WiFi - your devices know which WiFis are around and these companies can locate you because they have a database of SSIDs and their location. The API will give you the location, it's provider-agnostic (wifi, GPS, etc.). Works only in the foreground - won't work in the background/workers. Since the API is old, it's callback-based (no promises). MDN docs here.

4. Screen orientation API.

Green availability: if the device is in portrait or landscape mode. Other stuff is not yet widely available: lock the screen.

5. Touch events API.

They work with touch screens: touchstart, touchend, touchcancel, etc. Apple proprietary. MDN docs here. That is why the following API was created:

6. Pointer events API.

MDN docs here. Based on mouse events, and multi-pointer (they work with mouse, trackpad, touch pen, stylus, etc). YOu receive one event per touch interaction (ie. 3 fingers you get 3 events vs 1 event in touch event API above).

7. VirtualKeyboard API.

MDN docs here. This API lets us show/hide the virtual keyboard and know how much space it is taking in the screen.

8. Gamepad API.

MDN docs here. Greenlight API. High-level API (I don't need to know the specifics of the gamepad, and it's the minimum that all gamepads have i.e. if a gamepad has a speaker that is not common, so it is not supported via the API) and low latency. You create a requestAnimationFrame loop (60 fps) and you check the status of each button with a boolean.

9. Web HID API (HID = Human Interface Device).

MDN docs here. Limited availability (light-green).

Speech, voice, and camera

10. Web Speech API.

Speech recognition API

MDN docs here.

Speech synthesis API.

We can make the web app speak.

11. Shape detection API. Between yellow and red.

Barcode detector API. MDN docs here. Experimental, it is only available for Chrome on Android as of this writing. Chromestatus here

Face detector API. Experimental, it is only available for Chrome on Android as of this writing.

Text detector API (OCR). Experimental, it is only available for Chrome on Android as of this writing.

12. Media devices. It lets you open the camera and microphone, and get the stream.

13. Advanced control camera (aka Camera PTZ - Pan, Tilt, Zoom). Let's you manipulate the camera.

13. Augmented reality (AR, XR).

14. Screen Wake Lock API. MDN docs here. Light green (not supported on Safari on iOS).

External hardware and Devices

15. Web Bluetooth API. Limited availability. MDN docs here. FF and Safari don't implement it and looks like they will never do it, because of reasons. So only on Chromium-based browsers for now. Only with BLE devices (Bluetooth Low Energy).

16. Web Audio API. MDN docs here. Green. Low-level API that lets you generate dynamic audio, 3D audio, and ultrasound communication with devices. Sonic socket library for ultrasound communication between devices.

17. Web Midi API. MDN docs here. Limited availability (Chromium-based browsers only). It's similar but much older than HID.

18. Web serial API. Very low level API. MDN docs here. Experimental.

19. Web USB API. MDN docs here. Experimental. Low-level API for device vendors. You probably won't be using this API.

19. Vibration API. MDN docs here. Targeting phones only.

20. Battery status. MDN docs here. Doesn't work in many browsers.

21. Idle detection. MDN docs here. Limited availability.

22. Web NFC. MDN docs here. Limited availability.

Testing fundamentals

Pere Sola — Sat, 09 Mar 2024 16:51:08 +0000

Some notes from the Frontendmasters' workshop Testing Fundamentals by Miško Hevery.

Theory

We test because it is the path of least resistance.
Micro development model: develop - test - develop - test, etc. The question becomes: are tests are automated?
The magic of testing is how I design my code so it is easy to test. It is not about the tools or knowledge.

Kind of tests

Testing level: unit tests, integration tests (functional), system test (e2e), acceptance tests.
Automation: automated tests, manual tests.
Functionality: functional, performance, security, usability, a11y.
Other: regression (add tests when a bug is found and fixed to avoid the regression again), smoke (large system but running all tests takes hours, so you select a subset of tests for a sanity check).

Code

Unit testing (tools, TDD, mocking, dependencies, coverage, benchmark)

They use vitest in the course, but I guess it is a similar test runner to say jest syntax-wise.
You may have a function to test that calls an external service. It would work if you make the api call in the test, but it will get expensive (what if you are testing a card transaction..) and flaky (what if the service is down..). So mocking is like inserting a collaborator on the other side of the api call that returns the stuff you want for your test.
So to test fetch, instead of importing and calling it in the function, you pass it to the function so you can mock that function. Like:

const functionToTest = async (arg1, fetch) => {
    const response = await fetch(whatever)

    return response
}

So the test will have:

it('whatever', async () => {
    // This is the "pretend" fetch, but it doesn't know what to do yet
    const mockFetch = jest.fn<Type>()

    const response = functionToTest(whatever, mockFetch)

    expect(response).toWhatever()
})

You can do it.todo() while you are writting tests, they won't error out.
expect(object).toMatchObject(anotherObj) I think it is similar to the expect.objectContain(anotherObj). << TBD, I forgot the exact syntax.

Integration testing

Component testing (UI)

E2E testing

Accessibility for the web

Pere Sola — Sun, 25 Feb 2024 17:48:44 +0000

Photo by Hannah Busing on Unsplash

These are my notes from the excellent two Frontendmasters' courses about accessibility, by Jon Kuperman and Marcy Sutton.

Accessibility myth-busting

Screen readers use JS.
People use keyboards.
The days of "screen-reader" skip links and other "offscreen" only skips are over, they should be made visible too.
Navigating by voice is a big part of a11y.
Browsers cannot detect if someone is using a screen reader.

Overlapping areas

SEO. a11y doesn't affect the ranking but headers do, so headers help both a11y and SEO.
Add links are good for screen readers.
Performance. Faster load faster interaction.
Security. No a11y means a security flaw, because people cannot do it independently.
Business growth. The more a11y the more people can use your website.

Standards

WCAG (Web Content Accessibility Group). A standard set of criteria for measuring a11y. The current version is 2.2 (here). There is a looming 3.0 version. It is developed in open source in Github. Provides 3 conformance levels: A (lowest), AA (mid-range), and AAA (highest).
Aria (Accessible Rich Internet Applications) is a w3 spec (same group as CSS and HTML) and it is a set of accessibility helpers that you can apply to your HTML. The current ARIA version is 1.2 (here) and also developed in the open, in Github. Other ARIA-related non-normative documents (informative): ARIA in HTML and Using ARIA.
WebAIM - Web Accessibility In Mind. They provide a checklist. It is not an official spec but rather a way to make the WCAG specs more digestible.

Screen readers

Type of AT (Assistive Technology), both software and hardware. They convert text and graphic images to speech or Braille output.
iPhones and Macs have screen readers built in (VoiceOver). On Windows, users can use the built-in screen reader Narrator or install NVDA or JAWS.
There are many combinations and we can't test them all. WebAIM runs a survey every couple of years where you can see the most popular screen-readers for each platform. You can focus on these.
VoiceOver keyboard cheatsheet.
NVDA for Windows (free), Chrome screen reader, Voiceover for Mac.
Images. alternative text. The screen reader will read the file name if it doesn't find an alt text. Alt text will override this behavior. alt="" is empty alt text and the screen reader will not read it. This is useful if you have decorative images. Screen readers will ignore images in a CSS background. The alt text should be brief and descriptive. Lacking alt text is one of the top 5 a11y issues. Alt decision tree will help you decide if and what to write in the alt text.
X-browser testing - https://assistivlabs.com/ can help.
Audio. Needs captions.

Testing / Debugging

Steps to take:
STEP ONE: Tab key to navigate: can you reach and operate every interactive control? Can you see where your focus point is on the screen? Do you get trapped anywhere that you can't escape (see keyboard trapping below)? Can you use other common keys like arrows, ESC, key, and space key?
STEP TWO: Open a browser devtool extension like Axa. Prioritise violations over best practices.
STEP THREE: Zoom the browser to at least 200% (see reflow below).
STEP FOUR: Test light and dark mode. Ensure animation and motion can be turned off with Reduced Motion (see below).
STEP FIVE: Run a screen reader.
STEP SIX: Make note of missing transcripts or captions and other alternative content. Ensure media players and pages can accommodate this content.
Linters and dev tools: built in the browser, Chrome lighthouse, browser extensions, linters, Accessibility tab in Elements tab in Chrome.

Accessible HTML

Basics always apply: HTML needs to be valid, well structured, and using as many defaults as possible.
WELL STRUCTURED: structural semantics is very helpful in screen readers and other reader modes. Not divs all over the place.
AS MANY DEFAULTS AS POSSIBLE. Try to use as many defaults as possible because they come with a lot of a11y behavior for free.
You can do a lot by using semantic HTML. <aside>, <footer> and <header> don't have functionality but have semantic meaning. Others like <button>, <input>, and <textarea> provide a lot of built-in functionality. It is important to avoid generic HTML elements when more dedicated built-in elements exist. Avoid "div soup" or "divitis".
HEADERS: use h1-h6 headings to create a page outline. Style them with CSS. Avoid the HTML5 heading algorithm as it was not implemented for Assistive Tech. Use a heading based on what the content is, not how the content should look like. CSS doesn't influence screen readers. You should always use the appropriate heading and style it only if you ever need to.
LANDMARK ELEMENTS: nav, main, section, header, etc.
LISTS: they are great, a screen reader will say "5 items", or whatever. Don't add other types of descendants to a list element.
FORMS: very powerful elements, like <form>, <fieldset> and <legend>. Labels are essential for inputs/textareas/etc in Assistive Technology (AT). Explicit labels use for and id. Implicit labels wrap an input. Only certain elements can be labeled.
HTML labels. Explicit (using for attribute) or implicit (nesting input field) is the way to go. No label with div or p. Labels work for "labelable" items, such as: <button>, <input>, <keygen> (deprecated), <meter>, <output>, <progress>, <select> and <textarea>. If you need to label an element not on that list, use aria-label instead.
role. You can use an ARIA role to indicate to the screen reader that the div (or whatever other than a button) is being used as a button. Example:

<div role="button" onClick="() => alert('hey')">Click me</div>

^ This will tell the screen reader that the div can be clicked. But this won't let the div be focusable, so we have something called tab-index. That means that it can be focused with the keyboard. But if you are a keyboard-only user, you won't be able to click on the element. That's why we have onKeyUp (you can get precise and only listed to Enter or Spacebar. The last thing, we need an aria-label to label the element.

BUTTONS AND LINKS. HTML buttons give a lot of behavior for free: focusability, built-in-role, and keyboard click events. Links need an href to be accessible. Buttons toggle things and links navigate - use them appropriately.
DETAILS AND SUMMARY. Are built-in accordion-style disclosure widgets.
SETTING LANGUAGE. <html lang="en">. If language is dynamic, it can be set on a template. Element level vs page level language:

<html lang="en">
  <body>
    <p lang="fr"></p>
  </body>
</html>

ARIA

ARIA stands for Accessible Rich Internet Applications and it's a way to add accessibility information to your apps. As of winter 2023, the current version is 1.2 (specs here and MDN docs here).
ARIA and HTML work great together. Built-in roles for buttons, links, etc. (implicit roles) vs the ones we add with ARIA (bolt-on).
The major categories of ARIA are roles, states, and properties. i.e. role="button" or aria-hidden="true".
ROLES. Many HTML elements have roles built-in, such as <button> or <main>. They can also be bolted on to override the default semantics of an element. <button> has the implicit button role. <div role="button"> has the explicit button role. You should use the native HTML element with a role built-in.
ARIA attributes can be used as selectors in CSS. i.e. [role="checkbox"][aria-disabled="true"] {}
You can bolt-on accessible names and descriptions using explicit ARIA attributes like aria-label, aria-labelledby, and aria-describedby.
LIVE REGIONS. It allows the screen reader to "listen" to content change in the app and read it. i.e. uber app after a ride has been booked when it changes to "looking for a driver", "driver found", "driver is here", etc. This is done with aria-live and it has two values: assertive (interrupts reading to read the update) or polite, which will wait for the screen reader to finish reading. If it is off it will not read the update.
<label> is great but it only covers some elements. For the rest, you can use the following aria tools: aria-label, aria-labelledby, and aria-describedby.
aria-label and aria-labelledby do the same but the difference is similar to the explicit and implicit label: labelledby refers to an id of some previous element. That element would probably have to be visually hidden or sth. aria-describedby is about description, extended information that the user may need.
ARIA roles, states, and properties.

Focus management

Keyboard shortcuts. You can build them for your app to help folks who are keyboard users only.
Skip links. Allows you to go to main content, you can see examples in github.com or The New York Times. Create a visually hidden anchor with the body "skip to content", prepend it to the body, and give it a focus state in CSS.
Tab navigation. tab and shift-tab to navigate forth and back in a website. Tabable elements include <a>, <button>, <input>, <select>, <textarea>, <iframe>. To make a non-tabable element tabable you can use the tab-index attribute to achieve so. Negative means that the element is not reachable via sequential keyboard navigation. value 0 means it is reached by sequential tabbing and positive means that it takes priority. MDN docs here.
Active element. To know which one it is (in case it is hidden or you cannot find it) you can use document.body.addEventListener('focusin', () => console.log(document.activeElement)); in your browser console. It will print the element that has focus (active element API).
Keyboard trapping. Focus only on a subset of elements. The user's keyboard focus would cycle through the elements until they complete a task or close that layer (like in an accessible modal). Level A WCAG dictates that there should be no keyboard traps. React-aria can do it for you. Also, existing design systems libraries (i.e. Chakra UI) normally have accessibility incorporated into their components.
Keyboard shortcuts can be helpful.

Visual considerations

Color contrast

Tools you can use: Lighthouse audit, WebAIM contrast checker for the design phase, Chrome dev tools (more info here).
Colors and forms. Validation errors with red/green may not work for people with disabilities. Color only is not enough, you should put some text or label.
Visual impairments. Firefox extension called NoCoffee. Keeping things together helps because people may have a narrow vision field.
Setting the language. In the top level html and for certain text that deviates.
Fix markup errors. You can use https://validator.w3.org/.

Reflow

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for. Specs can be found here.

Reduced motion

prefers-reduced-motion. You can access the motion a11y settings from the system to change your code, like CSS animation (i.e. from pulsing to something softer).

Color preference

Same for the system color preference, dark or light. You can access it with:

@media (prefers-color-scheme: dark) {
     .main {
       background: black;
       color: white;
     }
}

@media (prefers-color-scheme: light) {
     .main {
       background: white;
       color: black;
     }
}

Tooling

Linters

https://www.npmjs.com/package/eslint-plugin-jsx-a11y for React

Accessible Design Systems

Accessibility Developer Tools

To do audits. Deque and Google's Lighthouse.

More resources

https://learn-a11y.netlify.app/resources/ (Jon's course website)
https://web-accessibility-v3.vercel.app/ (Marcy's course website)

Functional JS

Pere Sola — Sun, 28 Jan 2024 15:48:04 +0000

I keep on forgetting some cool declarative methods in JS, so this is a reminder compilation for me to refresh my memory as I encounter them doing coding challenges.

Array.prototype.sort(compareFn). Mutates array "in place" after converting values to string and comparing UTF-16 code unit values. Values are sorted ascending. If you don't want to mutate the array, use toSorted. compareFn is called with a and b and should return a negative number if a is smaller than b, positive if a is bigger than b or 0 if they are the same. If compareFn is not supplied the array is sorted after comparing the values to their string form. More here.
Math.max(value1, value2, etc.) and Math.min(value1, value2, etc.). If the array has few elements, you can use it like Math.max(...array). It is best to use reduce:

const arr = [1, 2, 3];
const max = arr.reduce((a, b) => Math.max(a, b), -Infinity);

String.prototype.repeat(count). Repeats a string a count number of times. i.e. 'Hello'.repeat(3) return HelloHelloHello.
Array.prototype.some(cb) - returns true if one item in the array returns a truthy value when the callback is called upon or false otherwise. It stops iterating as soon as it find an element that returns a truthy value.
0 + true is 1 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Unary_plus#usage_with_non-numbers
new Set([1,1,3,2,2,3,4]) will get rid of the duplicates and return [1,3,2,4] because a set can't have duplicates.
address.split('@').pop() will return the domain in an email even when there are 2 @s.

Regex stuff

/^\d*/ < match any series of digits at the start. You can then do string.match(/^\d*/) to find a prefix made up of digits only.
'string'.match(regex) will return the matches. If the g flag is used, it returns an array with the matches. If not, just the first match. i.e. '010010000110010101101100011011000110111100100001'.match(/.{1,8}/g) will return an array of bytes.
String.fromCharCode(charCode) returns the ASCII string attached to the charCode.

Binary numbers

parseInt(binaryNumberString, 2) will return the integer of the number in whatever base we say. The example is base 2.

[WIP] The Hard Parts of UI development

Pere Sola — Sun, 14 Jan 2024 22:59:25 +0000

Notes from the course The Hard Parts of UI Development by Will Sentance in Frontendmasters.

Goal 1 - Display content on the screen

Layout engine works out page layout for specific browser/screen.
Render engine produces the composite ‘image’ for graphics card.
html > DOM in C++ (webcore) > visual content. html is a one time addition of elements into the DOM.
CSS > CSSOM (mirrors the DOM) in C++ > styling the content above
Render engines creates an image of the page, which gets sent to the graphics card and updated 60 times a second.

Goal 2 - Let users change the content / interact with it

html is a one time addition of elements to the DOM (in C++). Changing content on the screen changes the DOM. However, we cannot run code on the DOM. Javascript is needed.
When we load a url in the browser: 1) we open the html file, html is parsed by the html parser and creates the DOM (in C++); 2) the html file has a reference to the JS file, which will start loading by the JS engine, with its own thread of execution, memory, execution context, etc.; 3) JS links to the C++ DOM runtime via the document object and all the methods available to it: document.querySelector, etc.
Web IDL (Interface Description Language) - standardised way to know how to access other parts of the browser from JS. DOM API is written in human language - its implementation in the browser will be described in the Web IDL.
const jsDiv = document.querySelector('div') uses the document object, which will give us access to the DOM API via a hidden link to the C++ DOM. It will allow us to grab a list of elements in C++. jsDiv will be assigned to the evaluation of document.querySelector('div'). That will be an object with properties that allow us to access and modify the C++ DOM element i.e. textContent. If we console log that element, instead of the C++ DOM element we get the html command that created the C++ DOM element!
textContent is the property of jsDiv in the document object that will update the DOM So it is a getter setter property, otherwise it would be confined to this object and would be of little use to us. other and others get added to the call stack.
The following code follows the steps described after:

// in app.html
<input />
<div></div>
<script src='app.js'></script>

// in app.js
let post = '';

const jsInput = document.querySelector('input');
const jsDiv = document.querySelector('div');

function handleInput() {
     post = jsInput.value;
     jsDiv.textContext = post;
}

jsInput.onInput = handleInput;

app.html loads; the HTML parser looks at each line and adds them to the C++ DOM from which we will produce the actual pixels of the webpage through the layout and render engine; the HTML parser will tee up the JS engine to run; this will give us access to the document object that has a reference to the C++ object, that we can run function on to search or add elements.
There is a division between "C++ land" and JS land (we are not able to write code directly into the C++ land. Once the HTML is parsed and the items added in the C++ object, the items appear in the screen.
When JS starts executing, we get a call stack and a global execution context, which has a pre-loaded object: document. This object allow our JS to interact with the C++ object: querySelector (this is one type of accessor object), etc. They not only have action in JS but also in the C++ object.
The JS above: 1) define const post assigned to empty string 2) document.querySelector('input') will call the querySelector getter/setter in the document object, which will bring us to the C++ object 3) it finds it but because the C++ object cannot be brought back a corresponding object gets produced in JS with a link to the underlying C++ object; 4) that newly produced object is assigned to jsInput; 5) that JS object has properties that will allow us to work with the C++ object: i.e. onInput, value, etc.; 6) same for jsDiv; 7) assign handleInput to a function declaration; 8) in the jsInput JS object representation of the C++ element we will use the setter onInput to assign it to the function declaration handleInput. That will add a handler in the C++ element that will trigger the execution of that function when a user inputs something in the input C++ object element; 9) user action writes something in the input (ie. "Hi") and that triggers an event which issues a command to the C++ element to execute its handler; 10) value in the input C++ element will be populated with Hi; 11) the Events API will trigger the function referenced in the C++ element handler and add the call to handleInput in the callback queue; 12) the event loop will grab that function execution from the callback queue when the call stack is empty and there i no more JS code to run in the global execution context; 13) the function call will be added it to the call stack; 14) an execution context will be created with its memory; 15) in memory the variable post will be assigned to the value of the property value of the jsInput object; 16) we look inside the jsDiv object for the setter textContext which is set to the value of post; 17) textContent updates the value of the underlying C++ element, which in turn updates the screen to show "Hi".

One-way data binding

It is a paradigm implemented by the frameworks (React, Vue, Angular, etc.) that restrict the back and forth between C++ and JS to make our lives easier as UI engineers.
Code:

// in app.html
<input />
<div></div>
<script src='app.js'></script>

// in app.js
let post = '';

const jsInput = document.querySelector('input');
const jsDiv = document.querySelector('div');

jsInput.value = 'What is on your mind?'; // view

function handleInput() {
     post = jsInput.value;
     jsDiv.textContext = post; // affect view!
}

function handleClick() {
     jsInput.value = ''; // affect view!
}

jsInput.onInput = handleInput;
jsInput.onClick = handleClick;

jsInput.value sets the C++ value to the value set in JS and that renders the string in the screen; user action click input: sends an event to the DOM to trigger the handler which adds the function to the JS callback queue; event loop grabs the handleClick and adds it to the call stack; handleClick is called and an execution context is created; the value setter of jsInput gets sets to an empty string, updates the value in the C++ element, which updates the string; next user action: input; they will write whatever, which will trigger the C++ element handler, add the function to the callback queue, event loop will add it to the call stack, new execution context, the value property of the jsInput object will be assigned to post, and that string will be set to the textContent setter, which updates the C++ element, which updates the screen.

Asynchronous JS stuff

Pere Sola — Sun, 07 Jan 2024 21:05:54 +0000

Notes from The hard parts of asynchronous Javascript course in Frontendmasters, by Will Sentance. The links above are related to the topic.

When the code runs: global execution context. 1) Thread of execution (parsing and execution line by line) and 2) Global Variable Environment (memory of variables with data).
When a function gets executed, we create a new execution context. 1) thread of execution (go through the code in the function line by line) 2) local memory (variable environment) where everything in the function is stored (garbage-collected when the execution context is over).
Keeping track of the execution context needs the call stack. The global execution context will always be at the bottom when we are running the code.
Synchronicity and single threaded are two pillars of JS. How to make it asynchronous not to block the single thread?
Web APIs are not part of JS (see here), but allow JS to do more stuff. Web APIs are in the web browser.
Stuff outside JS is allowed back in (i.e. setTimout(printHello, 1000)) when 1) I have finished running all my code (the call stack is empty) and 2) the call stack is empty. The stuff "outside" (the browser feature) gets added the the callback queue (called task queue in the specs) before it's allowed back in. Only when 1) and 2) are done, JS looks inside the callback queue and adds it in the call stack. That's called the event loop. And only when the function printHello is added to the call stack the code inside will run (printHello doesn't run "inside" setTimeout).
Promises interacts with this world outside JS but it immediately returns an object (a Promise object), which acts as a placeholder of the data that will come later. The data will eventually be in the value property. Promises have an onFulfilled hidden property that runs when the data is available (array of functions that run when value gets updated). "Two pronged" solution: JS 1) returns the Promise with a placeholder and 2) initiates the browser work (xhr request). We don't know when value will be filled with data, so we add functions inside the onFulfilled that will run once we have the data, with value as input to these functions. .then adds a function to the onFulfilled array. When these functions run, they are added to the microtask queue (job queue in the specs). The event loop prioritises tasks in the microtask queue over the callback queue (the microtask queue should be empty before the callback queue is allowed in the call stack. The promise has another properties, status with 3 possible values: pending, fulfilled and rejected. The rejected status will trigger a similar array to onFulfilled, but called onRejected. We add function there with the .catch (or the 2nd argument to .then (see mdn here).
Closure === lexical scope reference. Iterator is a function that when called and executes something in an element it gives me the next element in the data. Iterators turn our data into "streams" of data, actual values that we can access one after another. The "closed over" data is stored in a hidden property called [[scope]].
Generators. Defined with a * in the function declaration (i.e. function* createFlow() {}). When we call createFlow (createFlow()), it returns a Generator object (mdn docs here) with a next method (here), that can be called afterwards. Like the code below. Generator functions do not have arrow function counterparts.

function *createFlow() {
    yield 4;
    yield 5;
}

const returnNextElement = createFlow()
const elementOne = createFlow.next()
const elementTwo = createFlow.next()

Calling the .next of a generator object creates an execution context, with a local memory. When yield is reached, the execution of this context is "paused". The returned value of next is:

{
    value: 4,
    done: false, // or true if we are yielding the last value
}

When we pass values to next the first yield will not return any value, because of the power of the yield keyword which, like return kicks us out of the execution context. Next time we call next with a value, the previous yield will evaluate to that value, and the execution resumes. See example in the course (~17.25 in Generator Functions with Dynamic Data lesson) and in mdn.
The "backpack" (closure) of the generator has not also the line where execution "stopped", which allows us to continue execution when next is called.
In asynchronous JS (i.e. fetch):

function doWhenDataReceived(value) {
    returnNextElement.next(value);
}

function* createFlow() {
    const data = yield fetch(url);
    console.log(data);
}

const returnNextElement = createFlow();
const futureData = returnNextElement.next();

futureData.then(doWhenDataReceived)

^ 1) Create const returnNextElement to which the return value of createFlow gets assigned (`generator object); 2) create const futureData 3) we open createFlow execution context and we reach the yield keywords, which "pauses" the execution of the function and allows to assign to futureData the promise object created by calling the fetch API; 3) .then adds that function to the onFullfilled array in the promise object (it will get triggered when the value of the promise is updated); 4) the fetch api returns the data, and the function inside onFullfulled gets added into the microtask queue (job queue officially) and, since the call stack is empty + no more code to run, it gets added into the call stack; 5) doWhenDataReceived execution context starts, it calls the .next from the generator object, which brings us back to createFlow where the execution was paused; 6) data gets assigned the value of the promise, and then we resume execution of the rest of the code inside that execution context.
async / await simplifies all this. The resumption of createFlow is done automatically. But this still gets added to the microtask queue:

`
async function createFlow() {
console.log("Me first");
const data = await fetch(url);
console.log(data);
}

createFlow();

console.log("Me second");
`

await is similar to yield, it throws you out of the execution context. 1) define createFlow; 2) call createFlow and open an execution context; 3) console log "me first"; 4) define data variable - we don't know what it will evaluate to but the fetch creates a promise object, which triggers a browser xhr request - the promise object has the value property and the onFullfilled; 5) await, like yield, kicks us out of the execution context and pauses it; 6) console log "me second" runs; 7) when the data is back, the execution of createFlow resumes by assigning the variable data to the value of the promise; 8) console log data.

Fix Cannot GET using VSCode Live Server extension

Pere Sola — Fri, 05 Jan 2024 16:12:16 +0000

I was recently working on a vanilla JS project and doing a vanilla JS client router. I was developing it using the VSCode Live Server extension. When in a given route i.e. /order and refreshing the browser page I was getting the Cannot GET /order.
I am not sure I would do a good job explaining why this happens (this SO answer does it). But I know how to fix it!
Head to the vscode extension settings and set index.html under the Live Server > Settings: File. It will start working.

How to allow or prevent VSCode from removing the file extension in imports

Pere Sola — Thu, 04 Jan 2024 00:05:43 +0000

There is a setting called Import Module Specifier Ending that you can tweak: