Justin Lowery cerebrl

Accessibility

General Learning

Login Widget with React JS

Requirements

Node 18+
NPM 8+

Configure Your ForgeRock Server

Ensure CORS is enabled

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:

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' });

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:

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:

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

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

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

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

	function prvtWriteToConsole() {
	console.log(greeting);

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