cerebrl

Accessibility

General Learning

1. Mozilla's Development Docs on Accessibility
2. Accessibility on web.dev
3. IBM Accessibility Requirements
4. Smashing Magazine's Accessibility tagged articles
5. UK's Guidance and Tools for Accessibility

cerebrl

Login Widget with React JS

Requirements

1. Node 18+
2. NPM 8+

Configure Your ForgeRock Server

1. Ensure CORS is enabled

cerebrl

Registering a custom callback

Fair warning: you are going to wade into advanced usage of the SDK, so prepare yourself for a complicated topic :)

To do this, you have a few options when it comes to custom callback handlers. It really depends on how much you want to preserve of the default handlers of the JavaScript SDK. Essentially callback handlers are JavaScript classes that provide better ergonomics around handling the callbacks that come from AM. They do this by "decorating" the plain JSON object that represents the current journey/tree node in AM with prototypal methods (I hope this makes sense).

Because the object that contains the callback is still just a JavaScript object at its core, you are not required to mutate its values through the SDK provided callback handlers exclusively. You could write your own getters and setters for the data, and use them independently have the provided callback handlers.

The main concept is that you receive a step object after calling next:

cerebrl

Playwright Test Issue Explained

Okay, I figured it out. Luckily, it’s quite simple (once it clicks). I’ll break down the test and why it fails line by line.

Here’s the test as a whole, and it fails every time due to line 22:

await page.goto('widget/modal?journey=LoginWithConfirmationAndChoice');

const loginButton = page.locator('button', { hasText: 'Open Login Modal' });

cerebrl

High Performance Web Apps for HTTP 1.1

Question:

Is anyone aware of bottlenecks when code splitting in HTTP 1.1? Perhaps better put: is there a point of diminishing return in terms of bundle sizes and network calls.

In other words: Is it better to request 5 x 200kb requests or 10 x 100kb files?

Given that http 1.1 caps at 6 requests per one origin in chrome, and 10 total, I’m curious if the 5 extra network requests above are going to negatively impact performance in terms of initial loads.

Answer:

Since HTTP 1.1 has been around for a long while, I’d say the industry has already decided what the best architecture is for optimal network performance [1], and, if I remember correctly:

cerebrl

Rewriting Git History

Say you have a code base that you just created and you have two commits locally:

commit a
commit b

This is your “version history”. You then push these commits to your remote. Now you have two repos with the same history:

cerebrl

The layered cake of testing

1) Static code analysis

This includes linting, type checking, code-flow analysis ... TypeScript, Reason, Flowtype, ESLint, TSLint are all examples of static code analysis.

When to run

These should run as frequently as possible. Optimally, they are continuously running while developing.

Code smells

1. Ambigious types on large objects, like TypeScript's any
2. Overly typing entities, rather than allowing for type inference

cerebrl

/** ****************************************
 * Constructor for say hi feature.
 * @constructor SayHiConstructor
 * @returns {object}
 */
function SayHiConstructor() {
	this.greeting = "Basic module says, 'hallo'!"
}
SayHi.prototype.sayHi = function sayHi() {
	this.writeToConsole());

cerebrl

/** ****************************************
 * Module for say hi feature
 * @module sayHiFactory
 * @returns {object}
 */
function sayHiFactory() {
	var greeting = "Basic module says, 'hallo'!"
  
	function prvtWriteToConsole() {
		console.log(greeting);

cerebrl

/** ****************************************
 * Utility file
 * mixin.js
 * @returns [object]
 */
function mixinFactory() {
	var len = arguments.length,
		i = 0,
		finalObj = {};