DEV Community: Jenning Ho

How I Use AI Councils to Solve Ambiguous Engineering Problems

Jenning Ho — Wed, 24 Jun 2026 16:41:10 +0000

A Practical AI Council Workflow for Software Architecture and Delivery

One AI Assistant Is Useful, But Not Always Enough

If you've used an AI coding assistant for anything beyond autocomplete, you've probably noticed a pattern: single-model workflows converge fast. Sometimes too fast.

You describe a problem. The model proposes a solution. The solution looks reasonable. You implement it. Then three days later, during review or integration, you discover the architecture didn't account for a boundary condition, a simpler alternative existed, or the design coupled two things that should have stayed separate.

This isn't a failure of the model. It's a failure of the process. A single model — no matter how capable — can commit early and refine within its own frame. It may not challenge its own assumptions the way a second engineer would.

Source-grounded coding agents — tools like Qoder, Codex, Claude Code, Cursor, Devin, Copilot Agent, or similar agentic coding environments — are powerful precisely because they work within your actual codebase. They can work within your repository, inspect relevant files, follow visible conventions, and run verification commands when the environment supports it. But source grounding doesn't eliminate architectural blind spots. It means the model knows what exists. It doesn't guarantee the model will challenge whether what exists is the right foundation for what you're building next.

For ambiguous engineering problems — cross-cutting refactors, unclear ownership boundaries, specification work for complex features — one assistant isn't always enough. Not because the model is bad, but because critique is a separate function from proposal.

Before going further, this is not a claim that AI councils are a new idea.

The broader pattern already exists in different forms: LLM councils, multi-agent debate, role-based review, self-critique workflows, and multi-agent software development systems. What I’m describing here is narrower and more practical: how I’ve been operationalizing that idea for software architecture and delivery work.

The useful question is not “can multiple models review the same problem?” We already know they can.

The useful question is: how do you turn that into a repeatable engineering workflow with clear roles, stop criteria, source grounding, implementation separation, audit, and human governance?

In this post, “AI council” does not mean a special platform. It simply means multiple AI contexts reviewing the same proposal from intentionally different roles.

How I Stumbled Into the Workflow

I first started consulting multiple AI models out of necessity, not grand strategy.

The immediate triggers were token and context limits. I was working on a complex specification in my agentic coding environment, and the context window was filling up. I couldn't fit the entire problem description, the existing codebase context, and a meaningful back-and-forth critique into a single session. So I started asking other models to review pieces of the proposal independently.

The early process was messy. I'd copy my coding agent's architectural proposal into another model, ask "what's wrong with this?", then paste the response back. Sometimes I'd ask a different model about an unfamiliar distributed systems concept to check whether my agent's approach aligned with established patterns. Sometimes I'd ask yet another to play devil's advocate on a trade-off decision.

There was no consistent order. No defined roles. No stopping criteria. Feedback came in random order. Objections weren't consistently tracked. Conversations could go too long. I'd keep going until I felt like I'd heard enough, or until I ran out of patience for copy-pasting between windows.

But even in this messy state, I noticed something: the final specs were better. Not marginally better — noticeably better. My coding agent's proposals would shift in meaningful ways after I fed back external critique. Assumptions got surfaced. Simpler alternatives appeared. Edge cases got caught before implementation rather than during audit.

Different models exposed different blind spots. The process worked. It just needed structure.

The Real Insight: It Was Not About More Models

After several runs, I realized the improvement wasn't coming from more models. Four models saying "looks good" adds nothing. More models alone can create noise.

The improvement came from specific structural properties:

Role separation: Each external model was implicitly playing a different role — critic, simplifier, systems thinker. When I made these roles explicit, the feedback got sharper.
Structured critique: Asking "review this" produces vague responses. Asking "identify the three biggest architectural risks in this proposal" produces actionable feedback.
Objection tracking: Without a ledger, feedback gets lost. Objections get raised and then quietly dropped. Tracking forces resolution.
Synthesis as a first-class step: Manually reconciling five responses is exhausting and error-prone. Making synthesis an explicit operation — performed by a source-grounded agent that can validate claims against the actual codebase — turned it into a reliable process.
Source grounding: The synthesis agent validates against reality. External models speculate; the source-grounded agent checks what's actually true in the code.
Implementation audit as a separate phase: Writing code and reviewing code are different cognitive modes. Separating them into different contexts preserves independence.
Human governance gates: The human doesn't synthesize everything manually. But the human decides when to stop, when to proceed, and what risk to accept.

"The value was not asking more models. The value was turning AI usage into a governed engineering workflow."

This distinction matters. "AI brainstorming" is easy to dismiss. An engineering process with defined roles, tracked objections, synthesis operations, and governance gates is something you can reason about, improve, and trust.

The Workflow in One Diagram

Problem Statement
  → Source-Grounded Architect Agent
    → AI Council Role-Based Critique
      → Feedback Synthesis
        → Objection Ledger + Open Questions
          → Human Governance Gate
            → [If blocking issues remain: repeat council round]
            → [If resolved: proceed]
              → Spec + Implementation Plan
                → Executor Agent (separate context)
                  → Auditor Agent (separate context)
                    → Audit-Driven Remediation (if needed)
                      → Human Final Approval
                        → Commit / Ship

Stage-by-stage breakdown:

Problem Statement — The human frames the problem clearly. This is the input to everything else.
Source-Grounded Architect Agent — A coding agent with full repository access produces an initial proposal including architectural options, trade-offs, and open questions explicitly flagged for review.
AI Council Role-Based Critique — Each council role (in a separate context or window) receives the same proposal and reviews it through their assigned lens. Responses are collected with role labels preserved.
Feedback Synthesis — All council responses are fed back to the source-grounded agent, which critically evaluates the feedback, identifies agreements, conflicts, and actionable items.
Objection Ledger + Open Questions — Objections are tracked with status, severity, and resolution. New objections are added. Resolved ones are marked.
Human Governance Gate — The human reviews the ledger and decides: are there blocking objections remaining? Are there meaningful open questions? If yes, another council round. If no, proceed to spec.
Spec + Implementation Plan — The architect agent writes the specification and plan incorporating all accepted feedback and resolved objections.
Executor Agent — A separate context implements the plan. This context focuses purely on implementation, not design debate.
Auditor Agent — Another separate context audits the implementation against the approved spec and plan. Independent review.
Audit-Driven Remediation — If audit findings require changes, they go back to the executor. The human approves this loop.
Human Final Approval — The human reviews the final state and decides whether to commit, open a PR, or ship.”.

The Role Model

Role	Typical Tool	Purpose	Output
Source-Grounded Architect	Agentic coding environment with repo access	Produce source-grounded proposal, synthesize feedback, write spec	Initial proposal, synthesis reports, spec + plan
System Thinker	Any AI model (separate context)	Evaluate systemic implications, coupling, boundaries	Architectural risk assessment
Critical Reviewer	Any AI model (separate context)	Challenge assumptions, find logical gaps, stress-test claims	Objections with severity and evidence
Simplifier	Any AI model (separate context)	Identify unnecessary complexity, propose simpler alternatives	Simplification proposals with trade-offs
Alternatives Reviewer	Any AI model (separate context)	Explore approaches the architect didn't consider	Alternative designs with comparison
Executor Agent	Agentic coding environment (separate context)	Implement the approved plan faithfully	Working code + implementation report
Auditor Agent	Agentic coding environment (separate context)	Independently audit implementation against spec	Audit findings classified by severity
Human Governor	Human	Govern stage transitions, accept risk, approve delivery	Go/no-go decisions at each gate

A note on tooling: Tools like Qoder, Codex, Claude Code, Cursor, Devin, Copilot Agent, or similar agentic environments can fill the source-grounded roles — provided they can inspect a repository, reason over code, edit files, run verification commands, and support separate working contexts. The council reviewer roles can be filled by any capable AI model.

A note on role assignment: The same underlying model can hold multiple roles. What matters is that each role operates in its own context. A model playing "Critical Reviewer" should not simultaneously hold "Architect" context. Role separation is about preserving independence of perspective, not requiring N different model providers.

The Objection Ledger

This is what turns AI discussion into engineering governance. Without tracking, feedback rounds become circular. Objections get raised, discussed, and then quietly dropped without resolution. The objection ledger prevents feedback from becoming vague opinion exchange. It makes objections explicit, trackable, and resolvable.

Every objection raised during council rounds gets logged:

ID	Objection	Raised By	Severity	Status	Resolution	Rationale
OBJ-001	Coupling between X and Y creates deployment dependency	Critical Reviewer	High	Resolved	Introduced adapter boundary	Decouples deployment without adding runtime overhead
OBJ-002	Simpler approach using existing queue available	Simplifier	Medium	Accepted	Revised to use existing queue	Reduces new infrastructure; trade-off: slightly less flexibility
OBJ-003	Edge case under concurrent writes not addressed	System Thinker	High	Deferred	Documented as future hardening	Low probability in current traffic; will address in v2

Statuses:

Open — Raised but not yet addressed
Accepted — Objection is valid; changes will be made
Rejected — Objection considered but not adopted (rationale required)
Deferred — Valid but explicitly out of scope for this iteration
Resolved — Accepted and corresponding changes are complete

Council rounds stop only when:

No blocking open questions remain
No unresolved severe objections remain
Accepted objections have corresponding changes reflected in the proposal
Rejected objections have documented rationale
Deferred items are explicitly marked as out of scope or future work

Six months later, you can look at the ledger and understand why the architecture looks the way it does. That's not just process overhead — it's an auditable decision record.

Human in the Loop, But as Governor

A common misconception about multi-model workflows is that the human becomes a copy-paste bottleneck — manually reading five responses, mentally reconciling conflicts, and rewriting the proposal by hand.

That's not how this works.

The source-grounded agent performs synthesis. It reads all council responses, identifies agreements and conflicts, evaluates each objection against the actual codebase, and produces a structured synthesis report. The human doesn't need to manually reconcile anything.

What the human does own:

Deciding when council feedback is sufficient — when to stop iterating
Approving transition to spec writing — the green light to commit direction
Approving remediation after audit — deciding what gets fixed vs. deferred
Deciding how many audit rounds are enough — diminishing returns exist
Accepting final delivery risk — the buck stops here

"AI does most of the work. The human owns the gates."

This is closer to "human as engineering manager" than "human as manual worker." You're not doing the synthesis. You're governing the process and accepting accountability for the output.

Why I Separate Architect, Executor, and Auditor

This is a practical decision, not a theoretical one.

The Architect context accumulates reasoning: the original problem, council feedback, synthesis reports, objection ledger, and design rationale. This context is essential for writing a good spec but would pollute an implementation session.

The Executor context starts fresh with the approved spec and plan. It focuses purely on implementation — file changes, test writing, integration. No design debate. No "should we reconsider the approach?" The spec is the spec.

The Auditor context starts fresh with the spec, plan, and changed files. It reviews independently. Because it wasn't involved in implementation, it doesn't share the implementer's assumptions or blind spots.

This mirrors real engineering practice: the architect who designed a system shouldn't be the only reviewer of its implementation. Separation of concerns applies to AI workflows just as it applies to code.

Practically, context separation also prevents role confusion. A context that has been arguing about architecture for an hour will approach implementation differently than one that received a clean spec. The executor doesn't need to relitigate design decisions. The auditor doesn't need to be sympathetic to implementation difficulty.

A Lightweight Version You Can Try

You don't need the full workflow to get value. Here's a practical starter version:

Write a clear problem statement.
Ask your coding agent for an initial proposal.
Send the proposal to two reviewers:
- Critical Reviewer ("find the three biggest risks")
- Simplifier ("what's unnecessarily complex?")
Collect feedback with role labels.
Ask your coding agent to synthesize feedback critically.
Track objections in a small ledger (a markdown table works fine).
Proceed only when objections are resolved or deferred with rationale.
Ask for a spec and implementation plan.
Implement in a separate context.
Audit in a separate context.
Remediate if needed.
Ship only after human approval.

Checklist:

Before Council

[ ] Problem statement written
[ ] Source-grounded proposal created
[ ] Roles selected (minimum: Critical Reviewer + Simplifier)

During Council

[ ] Same proposal sent to each role
[ ] Feedback collected with role labels
[ ] Synthesis performed
[ ] Objection ledger updated

Before Implementation

[ ] No blocking objections
[ ] Plan/spec written
[ ] Acceptance criteria defined

Before Shipping

[ ] Implementation reviewed by independent auditor
[ ] Audit findings resolved or deferred
[ ] Human approval given

Start with this. Run it three times. You'll find your own refinements quickly.

A Small Hypothetical Example

To make this concrete, here's how the workflow might play out on a common engineering problem.

The problem: A team needs to refactor a shared validation layer used by multiple modules. The current validation logic is duplicated across three services, with subtle inconsistencies. The team wants to unify it.

Source-Grounded Architect proposes: Extract a shared validation library, define a canonical schema, migrate each service one at a time with feature flags for rollback.

Critical Reviewer identifies: Migration risk — if the shared library has a bug, all three services fail simultaneously. The proposal doesn't address versioning or backward compatibility for services that can't migrate immediately.

Simplifier challenges: The feature flag approach adds complexity. If the new validation is strictly a superset of the old, why not just swap in-place with good test coverage? The abstraction layer proposed (strategy pattern with injectable validators) may be over-engineering for what's essentially string and schema validation.

Alternatives Reviewer suggests: Incremental rollout using the strangler fig pattern — new requests go through the new validator, old requests continue on legacy until traffic proves the new path is stable.

Synthesis updates the plan: Adopts incremental rollout (strangler fig) instead of big-bang migration. Drops the strategy pattern in favor of a simpler shared module with versioned schemas. Adds a compatibility test suite that runs both old and new validation on the same inputs to catch divergence.

Objection ledger resolves the concerns:

ID	Objection	Status	Resolution
OBJ-001	Simultaneous failure risk	Resolved	Strangler fig eliminates big-bang risk
OBJ-002	Over-engineered abstraction	Accepted	Simplified to shared module
OBJ-003	No versioning strategy	Resolved	Versioned schemas with compatibility suite

Executor implements the shared module with versioned schemas and the dual-run compatibility test suite.

Auditor catches one spec drift: the executor added an optional "strict mode" parameter not in the spec, which would create an implicit API contract. Flagged as a deviation.

Remediation fixes it: Strict mode removed. If needed later, it goes through its own spec cycle.

The point of the example is not the exact implementation detail. The point is that the council changed the shape of the solution before code was written: from a risky big-bang migration to a safer incremental rollout, with unnecessary abstraction removed before it became implementation debt.

What This Workflow Is Not

Let me be explicit:

Not a claim that AI councils are new. The concepts of LLM councils, multi-agent debate, multi-agent workflows, and role-based AI review exist publicly. I didn't invent the broad idea.
Not a fully autonomous engineering system. Human governance is intentionally preserved at every gate.
Not a replacement for human accountability. The human accepts delivery risk. AI provides proposals, critique, and implementation — but the human owns the outcome.
Not a workflow for every task. This is for ambiguous, high-risk, architecturally significant work. Using it for a trivial bug fix would be absurd overhead.
Not "just ask multiple models." The value is in the structure: roles, synthesis, objection tracking, source grounding, audit separation, and governance gates.
Not a requirement to use any specific tool. The methodology is tool-neutral. Any agentic coding environment that can inspect a repository, reason over code, and support separate working contexts can play the source-grounded roles.
Not a platform automation proposal. The process is the valuable part.

Automation can reduce clerical overhead later — routing prompts, collecting feedback, maintaining the ledger, generating artifacts. But that's optimization, not the core value.

When to Use It, and When Not To

Use this workflow for:

Ambiguous architecture where multiple valid approaches exist
Cross-cutting refactors that affect many modules or boundaries
High-risk implementation plans where getting it wrong is expensive
Unclear ownership boundaries between systems or teams
Incomplete documentation where the "right answer" isn't written down
Spec generation for AI-assisted implementation
Changes where implementation drift from intent would be costly

Do not use it for:

Trivial bugs with obvious fixes
Small, localized changes with clear paths
Low-risk UI changes where the worst case is a quick revert
Already-approved implementation paths
Work where speed matters more than design confidence

The overhead is real. It pays off when the cost of getting the design wrong exceeds the cost of the process.

Closing

AI councils are not valuable because they sound sophisticated or because multi-agent systems are trending in research papers.

They're valuable when treated as an engineering process — with defined roles, tracked objections, structured synthesis, independent audit, and human governance gates. Without that structure, consulting multiple models is just expensive brainstorming with extra steps.

What this workflow gives a single engineer:

An architecture review board — without needing to schedule five senior engineers in a room
An implementation team — that executes from a clear spec, not a vague description
An independent audit function — that reviews against intent, not just "does it compile"
A decision record — that explains why the design looks the way it does, months later

The goal is better judgment at higher speed. Not blind automation. Not replacing human accountability. Not claiming that AI can do everything unsupervised.

The method is portable across tools. The quality depends on the agent's source-grounding capability, its ability to run verification commands, and — most critically — the operator's governance discipline.

If you try it, start small. One critic. One simplifier. One synthesis round. One audit. See what it catches that you would have missed alone.

RxJS subscription management with Angular

Jenning Ho — Thu, 09 Sep 2021 11:27:52 +0000

Subscription of observables is the bread and butter of using RxJS. With each subscription, we create a Subscription and it is being held in memory. If not handled, the subscription will be kept in memory and potentially cause memory leak.

With this article, I'm going to cover the various methods to manage subscriptions and how to decide on which method to use. RxJS subscription management is one of the common mistakes among developers, partly due to the learning curve of RxJS, partly the opaqueness of subscription, yet it is essential to using RxJS effectively.

Put simply, managing RxJS subscription is to know when to unsubscribe. Anytime there is a subscription (a .subscribe() call), developer should know or be aware of when it will be unsubscribed, be it after nth emission, or when the component has been destroyed.

I'm going to cover 6 ways we can use to manage our subscription, and when to use them, not including any external libraries / plugins besides RxJS itself. Namely async pipe, first operator, take operator, takeWhile operator, takeUntil operator, and finally the .unsubscribe() call. Which to use is dependent on the context, ie. is the piped function (ie. side effects) complex? How often or how long should the subscription be kept alive?

async pipe

The first method that we should always try to reach for is the async pipe method. With async pipe, we won't need to handle the unsubscribe manually, both subscribe and unsubscribe will be handled for you in the Pipe. It unsubscribes from the observable as soon as the component is destroyed. Internally, it also handles the change detection for you. With async pipe, there'll be a lot less code in your .ts file. Less code, less bug.

`async pipe used in app.component.html`

<p>{{ data$ | async }}</p>

However, there's one caveat with async pipe method, it is that every time the UI re-renders in Angular, any async piped observable will trigger, causing any functions, operations or side effects in between to be triggered, as many times as the UI re-renders. If you have an expensive operation in between the pipe, it'll be heavy on the resources. Keep this in mind and move the heavy operations to a different stream of observable and handle them in the component's class (.ts) file.

Also, async pipe is really only applicable when the data needs to be printed in template. Still, it should be the first method we reach for to manage observable subscription when the situation allows.

Reference: AsyncPipe

first operator

Despite the name, the first operator is the second method we consider. With first operator, your observable subscription will be unsubscribed as soon as there's one emission that passes through. We can pass in a function as our predicate / validator to ensure that the one emission through this operator is the value that we want. This is the operator to go for when we know very surely that we'll only need one emission from the subscription.

const data$ = from([0, 1, 2, 3]);

// without requirement
// unsubscribed with one emission
data$.pipe(
  first()
).subscribe();

// output: 0

// with guard / validator function
// ensures only truthy value can pass through
// will only unsubscribe after one truthy value
data$.pipe(
  first(value => !!value)
).subscribe();

// output: 1

Reference: first

take operator

Similar to first operator, take operator accepts a finite number of emission, difference being that it can take more than one emission. One other difference being first will emit an error if the stream completes before a value is emitted, while take won't. Use this operator when you know only a finite number of emission is needed. You may also consider adding a filter operator to guard against the emissions to ensure that the nth number of emission that you get are of value to you.

const data$ = of(0, 1, 2, 3);

// takes 3 truthy value
data$.pipe(
  filter(x => !!x)
  take(3)
).subscribe();

// output: 1, 2, 3

Reference: take

takeWhile operator

takeWhile operator will keep the subscription alive while a condition is true. This operator will take in a predicate / validator function to determine the condition to be true or false.

const data$ = of(1, 1, 1, 2, 4, 8);

// take while value is less than 4
data$.pipe(
  takeWhile(value => value < 4)
).subscribe();

// output: 1, 1, 1, 2

It is not common to reach for this operator, however there are certain situation that calls for it, ie. we want the subscription to stop as soon as a condition is fulfilled. Another instance, we want to remain subscribed as soon as we hover on an element, and unsubscribe as soon as we leave.

Reference: takeWhile

takeUntil operator

takeUntil operator accepts an observable as its notifier that will tell it when to end the subscription. When the notifier is passed in to takeUntil operator, it will subscribe to that observable internally, and as soon as there's one emit from the notifier, it will unsubscribe from both the source and the notifier observable. Do note that the notifier observable is unsubscribed by takeUntil internally, hence it is unecessary to unsubscribe or complete the notifier observable if nothing else is subscribed to the notifier.

This operator is likely the most common operator that we'll use. If none of the above mentioned operators worked for your situation, then takeWhile will most likely be the one for the job. It is most often used to keep a subscription alive until an event happened, i.e. when a component is destroyed.

`takeUntil to end subscription when component is destroyed`

class AppComponent implements OnInit, OnDestroy {
  private readonly destroyed$ = new Subject<void>();

  ngOnInit() {
    const interval$ = interval(1000);

    interval$.pipe(
      tap(val => console.log(val)),
      takeUntil(this.destroyed$)
    ).subscribe();
  }

  ngOnDestroy() {
    this.destroyed$.next();
  }
}

When using takeUntil to end a subscription, make sure that you place it last in the chain of operators to ensure that it covers all the streams in between. This will prevent the subscription leak to streams that are after the takeUntil operator.

`takeUntil subscription leak`

const streamA$ = interval(1000);
const streamB$ = interval(50);
const notifier$ = new Subject();

streamA$.pipe(
  takeUntil(notifier$),
  switchMap(() => streamB$)
).subscribe();

notifier$.next();

In the snippet above, streamA$ would end after the notifier$ emitted, but streamB$ would not end, it's subscription would be kept alive and that is the takeUntil leak.

Reference: takeUntil

.unsubscribe()

Finally, we can simply call .unsubscribe() of a Subscription to end the subscription. You'll have to first assign your subscription to a variable, or a class property, then call .unsubscribe() when it is time to end the subscription.

`single subscription .unsubscribe()`

const interval$ = interval(1000);
const subscription = interval$.subscribe();

subscription.unsubscribe();

However, because we'll have to assign each subscription to a variable, it is a lot more work / code to do, and it is done very manually and imperatively compared to the few above mentioned methods. It is especially so when there are more than one subscription.

`batch subscriptions .unsubscribe()`

const subsciptions = [];
const interval$ = interval(1000);
const subscriptionA = interval$.subscribe();
const subscriptionB = interval$.subscribe();

subscriptions.push(subscriptionA);
subscriptions.push(subscriptionB);

subscriptions.forEach(subscription => subscription.unsubscribe());

Reference: Subscription

Conclusion

So I've covered 6 ways we can manage our RxJS subscriptions, ordered according to a heirarchy of decisions. Learn them, and decide for yourself which one is best suited to solve your problem in the context.

Worth mentioning, there's a library named UntilDestroy that can help you unsubscribe from observables when the component is destroyed. It's like takeUntil except you write less code.

That's all I have to share. Happy coding!

Improve your Javascript conditionals

Jenning Ho — Sun, 25 Jul 2021 16:37:33 +0000

Writing conditionals are unavoidable when building software. It is one of the key topics when learning Javascript. However, conditionals are also the biggest contributor to push our software into entropy. It is important to be clear and explicit with our conditionals to ensure the quality of our code is maintained.

Modern Javascript provide us a vast arsenal of tools and methods to help structure our code. Here are some tips to improve your Javascript conditionals:

1. Name your condition

The first and maybe the most impactful thing you can do to improve your code is naming things correctly, that includes when dealing with conditionals. After all,

There are only two hard things in Computer Science: cache invalidation and naming things.

Phil Karlton

Be explicit with what you're checking for when writing an if statement, especially so if its a multi-condition check. You may get a pass if its a short one liner with single condition.

BAD

if (item.group === 'fruits' && item.name === 'apple' && item.status === 'ripe') {
  // slice my apple
}

GOOD

const isAppleRipe = item.group === 'fruits' && item.name === 'apple' && item.status === 'ripe';

if (isAppleRipe) {
  // slice my apple
}

Another quick tip here: naming boolean type variable, start it with "is", or "should" or "has", that are intuitively of boolean nature.

2. Type coercion

Javascript is a dynamically typed language, that means variable in Javascript can switch data type on the fly if you're not careful. Understand what are truthy and falsy values, and type cast your conditional check into boolean using ! and !! (single and double exclamation). This is especially useful when writing Typescript that are type sensitive when return values.

const list = [];

const isEmpty = !list.length;
const isNotEmpty = !!list.length;

In most cases, you want to avoid explicitly checking for type. Ultimately it depends on the requirement, maybe in certain cases you want to be really explicit that you're checking for undefined, or null, but usually you can get away with simply casting them into boolean.

if (!isAvailable) {
  // do your thing
}

// instead of

if (isAvailable === null || isAvailable === undefined || isAvailable === false) {
  // do your thing
}

If you're using Typescript, you should instead leverage on it's capability by declaring variable type along side with the variable. Otherwise, default parameters in javascript can also help your case here. Design your software in a way where falsy or truthy value is expected.

BAD

function doYourThing = (isActive) => {
  if (isActive !== null || isActive !== undefined || isActive !== false) {
    ...
  }
}

GOOD

function doYourThing = (isActive: boolean = false) => {
  if (isActive) {
    ...
  }
}

In cases where we'd check for object property value, we're used to a long list of condition chaining, ie. item && item.name to avoid nullish reference error. We can now use optional chaining when checking for object property, which would return undefined if it is not available.

BAD

if (item && item.name) { ... }

GOOD

if (!!item?.name) { ... }

3. Guard clause

Guard clause is a fancy way to tell you to always return early. Write your conditions to exit a function, rather than conditions to enter a function, to put it succinctly:

BAD

function getUserSession(user) {
  if (!!user.name && !!user.password) {
    // proceed to get user session
  }
}

GOOD

function getUserSession(user) {
  if (!user.name || !user.password) {
    return;
  }

  // proceed to get user session
}

By exiting a function early with guard clause, you get the invalid cases out of the way first (the bouncer pattern), before proceeding with the "real" body of your function. This will effectively reduce your code indentation caused by multi-level nested if else statements that are hard to read and hard to edit.

Mentally it also helps your fellow developers to jump to the next function earlier without needing to read through the whole body of function.

4. Conditional operators

A lot of the times we need to assign values or call a function based on condition. We can use conditional operators to make our code a little cleaner and easier to follow. Which conditional operator to use will depend on the requirement.

When declaring a variable, we should minimize the need for re-assignment to help with predictability of your code. In the same spirit, it is good to prefer const when declaring a variable.

In cases where the value of the variable can be different if condition is true or false, we can use ternary operator to help shorten our code:

BAD

let itemGroup;

if (itemType === 'apple') {
  itemGroup = 'fruit';
} else {
  itemGroup = 'vegetable';
}

GOOD

const itemGroup = itemType === 'apple' ? 'fruit' : 'vegetable';

However, be mindful to not overdo it with multiple nested ternary operator. In cases where that is required, consider restructuring your logic or use one of the methods mentioned later in the article to handle conditionals with multiple outs.

In cases where we need to assign value if value is falsy, we can use OR || operator. If we want to be more explicit with our checking, to target only null or undefined we can use nullish coalescing operator.

const itemNameFalsyCheck = item.name || 'Name is falsy';

const itemNameNullOrUndefinedCheck = item.name ?? 'Name is null or undefined';

5. List check

There are many scenarios where we are dealing with a list of values, and we'll want to check for something in the list, either if value exist, or value is of certain type, etc.

If we're checking for multiple values we can use Array method .includes or Set method .has instead of chaining multiple OR operators.

BAD

const isFruit = (item.type === 'apple' || item.type === 'orange' || item.type === 'durian');

if (isFruit) { ... }

GOOD

const isFruit = ['apple', 'orange', 'durian'].includes(item.type);

// or

const isFruit = new Set(['apple', 'orange', 'durian']).has(item.type);

It is worth nothing that Set.has has a significant performance edge over Array.includes, especially when dealing with a large data set, it is worth fitting Set checking in your code when possible.

However in cases where Set has to be repeatedly re-initialized (ie. in a loop), the cost of initializing Set will be too big, the offset will result in worse performance, and in such cases it is better to stick with Array.includes.

BAD

const listOfFruits = list.filter(x => {
  const fruits = new Set(['apple', 'orange', 'durian']);
  return fruits.has(x);
});

GOOD

const listOfFruits = list.filter(x => ['apple', 'orange', 'durian'].includes(x));

If we're checking for any of the items in a list is of certain value, we can use Array.some:

const hasFruits = list.some(x => x.type === 'fruit');

If we're checking whether all of the items in a list if of certain value, we can use Array.every:

const itsAllFruits = list.every(x => x.type === 'fruit');

6. Multiple outs

In cases where we are checking for more than 2 outs, there are multiple ways to handle them without the need for multiple if else statement. It is in fact best to avoid multiple if else as it is notoriously hard to read, hard to edit, and also slower in performance in comparison to the few options that we have. They are namely, switch statements, object literals, and Map.

BAD

let itemGroup;

if (item.name === 'apple') {
  itemGroup = 'fruit';
} else if (item.name === 'carrot') {
  itemGroup = 'vegetable';
} else if (item.name === 'mazda') {
  itemGroup = 'car';
} else {
  itemGroup = 'fruit';
}

GOOD

let itemGroup;

// with switch
switch (item.name) {
  case 'carrot':
    itemGroup = 'vegetable';
    return;
  case 'mazda':
    itemGroup = 'car';
    return;
  case 'apple':
  default:
    itemGroup = 'fruit';
    return;
}

// with object
itemGroup = {
  apple: 'fruit',
  carrot: 'vegetable',
  mazda: 'car'
}[item.type] ?? 'fruit';

// with Map
itemGroup = Map()
  .set('apple', 'fruit')
  .set('carrot', 'vegetable')
  .set('mazda', 'car')
  .get(item.type) ?? 'fruit';

We can also use IIFE with switch to make our switch statement much more readable. Using IIFE to handle switch cases also open up your conditional check for data massaging before returning. Just be mindful and not overdo it, keep it small and simple.

const itemGroup = ((type) => {
  case 'carrot':
    return 'vegetable';
  case 'mazda':
    return 'car';
  case 'apple':
  default:
    return 'fruit';
})(item.type);

Conclusion

Be mindful when writing conditionals in your code. It is one of the foundation to becoming a solid Javascript developer. One last tip I have is to extract your commonly used check / validations into small utility functions. They are easily readable, testable, which will result in a less error prone system. That is all that I have to share when it comes to improving your Javascript conditionals. Happy coding!

Animated CSS loaders

Jenning Ho — Sat, 12 Jun 2021 11:46:27 +0000

Let's talk about a set of CSS loaders / spinners that I've made recently. A little brief on the idea and the technical details behind them.

Here is the set of loaders and their source code, written in plain HTML & CSS. The idea is to make them readable to anyone with some CSS understanding and hopefully inspire you to make one yourself.

They are rearranged for better display, not sequentially ordered.

The brief

With this set, I wanted to do some motion animation with 2 dots mixed with more advanced and tricky animation using 3d perspective, that relies a bit on sleight of hand principle for the visual to work.

The first and the main constraint I have is to make these with single HTML element. This is so that they can be easily applied to projects without complicating the code too much, which makes them practical.

Secondly without applying SCSS or SASS, I can't be doing a lot of hardcoded values, or multiple nth elements with loop. I mostly mitigate this constraint by using CSS custom properties. CSS custom properties is different from SASS variables, in the sense that they are not static. They are dynamic based on context, which you'll see from their application in this set. A good example is --loader-size-half applied in loader--7. By only setting --loader-size, --loader-size-half being an abstract calc function based on --loader-size, will also update its value accordingly.

This set contains mostly square and circles, as such they are always same height and width. Instead of setting both width and height manually, I choose to use the relatively new CSS property aspect-ratio. By only setting the width value, and setting aspect-ratio value to 1 / 1, it turns the element into square. Finally, border-radius 50% will make any element that has equal width and height into circles.

The .loader class

.loader {
  --loader-size: calc(var(--block-size) / 2);
  --loader-size-half: calc(var(--loader-size) / 2);
  --loader-size-half-neg: calc(var(--loader-size-half) * -1);
  --light-color: rgba(255, 255, 255, 0.3);
  --dot-size: 5px;
  --dot-size-half: calc(var(--dot-size) / 2);
  --dot-size-half-neg: calc(var(--dot-size-half) * -1);

  display: block;
  position: relative;
  width: var(--loader-size);
  display: grid;
  place-items: center;
  color: white;
}

This is the base class for all loaders. Within this class I've declared a few CSS custom properties that can be applied and reused in every loader.

.loader {
  --loader-size: calc(var(--block-size) / 2);
  --loader-size-half: calc(var(--loader-size) / 2);
  --loader-size-half-neg: calc(var(--loader-size-half) * -1);
  --light-color: rgba(255, 255, 255, 0.3);
  --dot-size: 5px;
  --dot-size-half: calc(var(--dot-size) / 2);
  --dot-size-half-neg: calc(var(--dot-size-half) * -1);
}

base loader size is half of block size, the container
--loader-size-half is a calc function that calculates half of loader size, which can be updated in real time by setting loader size value.
--loader-size-half-neg is simply half of loader size turned negative by multiplying it with -1.
light color is meant to be a constant to be used in many places.
dot size is the size of each tiny white circle, is set to 5px.

The elements inside each loader are centered by default with this 2 lines:

.loader {
  display: grid;
  place-items: center;
}

The color of all elements is also set in this base class with color: white, which sets the value of currentColor and be used in every other classes.

position: relative is set so that child elements' (::before and ::after pseudo elements) position: absolute are anchored to it.

The dots

They are made with each loader element's pseudo elements, ::before and ::after. With each HTML element, we actually have 2 child elements and 1 parent element to work with. A lot of the time we can create these presentational elements with pseudo elements. You can read more about them in MDN.

You will notice that most other elements are set to vmin value rather than px value, but dot is different. vmin values are directly tied to the viewport size, while px is not. Ideally the dot size should be vmin too, but why is it not?

This is mainly to make its position precise in relative the the line that each dots is "on". Ultimately when rendered on screen, the visuals are rendered in px and the smallest px on screen is 1px. The line is a static 1px size, and as such dot has to be too to make it "sit" on the line centered precisely. You can change dot's 5px value to any vmin value to see what I mean.

The loaders with dots can work with 4px ~ 6px sizes visually. So why 5px? So that it can be placed centered to the line. ie. 2px on top, 1px on the line centered, 2px at the bottom. This is the kind of calculation we should make to create pixel perfect layout.

The animation

A set of keyframes is declared for each loader despite some of them are the same set of keyframes to keep them separated and contained. Within each loader, the keyframes are reused by applying CSS custom properties. You can see them in action in loader 5, 6, 8, 9.

Most animation used in this set of loaders are simple translating (moving along the x, y, z axis) and rotating, but made interesting / unique via different easing and delay settings.

The subjects of each animation (ie. the dots) are actually doing the same motion, just one earlier than the other. This is achieved by simply setting a animation-delay to one of the dot. Instead of setting a positive delay, which will cause one of the element to pause for awhile before animating, I applied a negative delay. This allow the element to act earlier instead of later, and so skipping the initial pause while also creating the difference in delay.

When it comes to easing, I am not actually a wizard with bezier-curve calculation. I first have an idea of the outcome, ie. "snappy", "bouncy", "smooth, etc, then play with them in the devtool easing editor to come up with a suitable easing for the animation. ie. for loader 7, the effect is achieved by having an overly "bouncy" easing that allows the dot to go out of it's linear curve and comes back. While most other loaders simply have a "snappy" motion.

Conclusion

With this, I have shared my thoughts and some technical details behind creating this set of loaders. I hope you can pick up some css trickery from this and inspire you to make your own. Feel free to use any of this in your project too. Would make me happy to see actual application of this set. Happy crafting!

Responsive typography

Jenning Ho — Mon, 03 May 2021 15:20:13 +0000

This article is going to cover 3 common methods to create responsive typography for your website. Responsive typography is one of the core elements to a responsive website, it is about sizing your fonts as the website resizes itself. This is necessary to keep your content inline with the UI design, and that it doesn't break the layout of your website.

The 3 methods covered are namely media-queries, CSS clamp, and CSS calc. Here's a codepen that demo the 3 methods:

You may want to open the codepen in another window to play around with the viewport size (resizing the browser) to see how the content scale along the viewport, and observe the differences between the 3 methods.

media queries

Using media queries to scope the styling of an element is one of the most common method, as it is one of the earliest available CSS feature. It has the best browser support. You would define a breakpoint, and the styling for an element once the viewport is past the breakpoint.

.block {
    width: 50%;
}

@media all and (max-width: 800px) {
    .block {
        width: 100%;
    }
}

The above code would set .block element's width to 50% once the screen is above 800px, and 100% while it is below 800px.

similarly we can use this technique to set the font sizes of our content.

h1.title {
    font-size: 5rem;
}

@media all and (max-width: 800px) {
    h1.title {
        font-size: 2.5rem;
    }
}

This would set .title to 5rem when screen is above 800px, and 2.5rem while below 800px.

clamp()

CSS clamp function allow you to define a range of values, ie. the minimum value, current value, and maximum value of a property. With this in mind, we can apply a responsive view unit as the current value that allows the font to size according to viewport, then set a minimum and maximum font size to keep it within an acceptable range that works with your UI design.

h1.title {
    font-size: clamp(2.5rem, 8vw, 5rem);
}

This would set .title to be 8% of the width of your viewport, until 8vw is smaller than 2.5rem, then it would anchor to 2.5rem, or when 8vw is bigger than 5rem, it would stop growing at 5rem. This essentially means that .title will be within the range of 2.5rem and 5rem, while fluidly scaling according to the size of the viewport.

calc()

With CSS calc function you can write a math formula for your element's font size sizing behavior. The suggested formula for responsive font-size is a minimum absolute value plus a percentage value to create a responsive font size. ie. min + viewport size. The calculated outcome should work with your UI design.

Caution when using this method, as there isn't a maximum size for the font-size, but we can switch the percentage value to use vmin instead of vw to help limit it's growth.

h1.title {
    font-size: calc(1rem + 4vw);
}

This would set .title to 1rem + 4% of your viewport width. In other words, .title will never be smaller than 1rem while it fluidly resize itself accordingly.

Conclusion

Master these 3 methods and you'll create the next perfect responsive website. They're not methods that can only apply to font-sizes of your content, but also every part of your website. You may also mix media queries with either clamp and calc for more advance and intricate sizing behavior. Happy coding! 🥳

Resolve promises in sequence with RXJS (ConcatMap)

Jenning Ho — Tue, 19 Jan 2021 05:26:45 +0000

This article will be a short one mainly on resolving / handling promises in sequence using RXJS. One such example would be fetching a series of data, one after another, but only after the current one resolves.

The go to RXJS operator to achieve this is ConcatMap. When our use case requires sequentiality, ie. queueing a set of events to be resolved in order, we can consider ConcatMap as a possible solution.

ConcatMap when paired with RXJS's Subject will present you an easily modifiable, readable, function that can be adapted to most use cases. Here's the code:

from([1, 2, 3]).pipe(
    concatMap(id => {
        const res$ = new Subject();

        fetch(`url-to-api/${id}`)
            .then(res => res.json())
            .then(res => {
                res$.next(res);
                res$.complete();
            });

        return res$;
    })
).subscribe();

In the ConcatMap operator, we return a Subject.

This way, we can control the flow of the stream, we can decide when is the time to complete the current event and go to the next. The next request will not fire until the current one completes, which we'll do so via .complete() call.

In between the fetch response and the completion of the subject, it is the gap for us to perform any modifications, or actions that is required.

In closing, here's a codepen to demo the code above.

Organize styled-components theme in React with Functional Programming

Jenning Ho — Mon, 07 Sep 2020 10:46:01 +0000

Through this article, I'm going to show you one way to setup a theme for your React app using styled-components, and how to implement it in a structured and readable manner by applying functional programming practices.

styled-components

styled-components is a CSS-in-JS library. According to the State of CSS 2019 survey, styled-components is one of if not the most popular option for those opting for CSS-in-JS solution. It's not hard to see why, it gives us the best of ES6 and CSS.

To style a component we write CSS in template literals. The styling of the component can be adapted by passing a function that accepts component's props into the template literal.

const StyledButton = styled.button`
    height: 40px;
    background-color: ${props => props.primary
        ? 'white'
        : 'blue'
    };
`;

A button component style that will adapt its `background-color` based on component's prop `primary`.

styled-components appends a theme object to the props for you to access the values that are provided in the setup. The same code previously would be written like so to apply theme values instead.

const StyledButton = styled.button`
    background-color: ${props => props.primary
        ? props.theme.color.white
        : props.theme.color.blue
    }
`;

Accessing these theme value can get messy when you have a lot of them.

Functional programming

How does FP plays a role here? FP is its own subject, but for the purpose of this article, the key concepts we'll need are function composition and function currying. A simple explanation and example to illustrate each:

Function currying

A curried function is a function which takes multiple parameters one at a time.

const add = x => y => x + y;

The first function takes in the first argument, variable x and returns another function that is ready to take the second argument, variable y and finally returns the sum of x and y.

Function composition

Function composition in the simplest term is to combine multiple functions to create a new function.

const addDash = x => `${x}-`;
const oneDash = add(addDash(1));

oneDash(2); // outputs '1-2'

addDash function returns a string with a dash appended at the end of the argument. When it is passed into add it returns a function that will return a string with a dash in between first and second argument.

Ramda

In this article I will use my favorite FP utility library, Ramda to demonstrate. It provides us an arsenal of small functions that are ready to be curried to compose from. It is what I'm using in most of my React projects, if you like applying FP in your javascript projects do give it a go.

Setup

Your theme values will be provided in a ThemeProvider that comes with styled-components. To set it up:

const theme = {
    color: {
        white: '#ffffff',
        primary: '#3b49df'
    }
};

const Layout = ({ children }) => (
    <ThemeProvider theme={theme}>
        {children}
    </ThemeProvider>
);

Accessors

Accessors are functions to access your values. A simple props.theme accessor written in plain javascript can be:

const theme = props => props.theme

We'll compose increasingly complex accessor functions by currying them. I'll use the color accessor as an example:

import { path } from 'ramda';

const theme = (keys = []) =>
    props => path(['theme', ...keys], props);

const color = key => theme(['color', key]);

The path function from Ramda will return you the value based on the path that you've passed in (in the form of array).

The theme accessor will return a function that expects props as argument and returns you the theme object.

The color accessor takes the theme accessor and compose into a function that, again expects props as argument and returns you the color object.

Given that our props object shape to be...

const props = {
    theme: {
        color: {
            white: '#ffffff'
        }
    }
};

To get the value of white #ffffff, we'll call the color accessor with 'white', and that'll return us a function that expects props as argument. Which we can then do this...

color('white')(props); // outputs '#ffffff'

To review this in plain javascript, it is equivalent to...

const whiteColor = props => props.theme.color.white;

whiteColor(props) // outputs '#ffffff'

Because styled-components's template literal openings expect a function that takes props as argument, you can pass in these accessors to keep the code short and concise like so:

const StyledButton = styled.button`
    color: ${color('white')};
`

// is equivalent to
const StyledButton = styled.button`
    color: ${props => props.theme.color.white};
`

You can see from the snippet above how big of a difference it can make to your code. More complex accessors can be made by composing them with helper functions.

import { pipe } from 'ramda';

const props = {
    theme: {
        space: 10
    }
};

const space = (multiplier = 1) => pipe(
    theme(['space']),
    space => space * multiplier,
    space => `${space}px`
);

space(2)(props) // outputs '20px'

pipe will allow you to chain multiple functions together to create one big function. We chain the space accessor up with 2 other functions, a function that multiplies the base value of space (10) and another that appends the px unit, to come to the final output of 20px.

Helpers

Helper functions help us better compose our function for reusability, similar to mixins in SASS. Some simple helpers to get you started:

Appending unit

const px = x => `${x}px`;

All fixed sizes of elements should be provided as number value without its unit for ease of calculation and reference. Function like px will allow us to append px unit to our size value by composing it with the accessor function.

Media query

const mobile = x => css`
    @media all and (max-width: ${breakpoint('sm')} {
        ${x}
    }
`

A simple media query for targeting mobile styles. It'll make your media query look clean and simple.

const StyledSection = styled.section`
    height: 100vh;

    ${mobile(css`
        height: auto;
    `)}
`

css is a function provided by styled-components to forward the props.

Unit converter

const pxToRem = x => `${x / 16}rem`;

It is recommended to set values (ie. padding, margin, font-size) to rem, as that'll scale to user's browser settings. It does involve some calculation though. I like to set my values as px, and have a little helper function to convert px value to rem, so I can apply rem units without thinking about it too much.

Implementation

Here's a snippet that shows how your code can look like...

import styled from 'styled-components';
import { height, color, space } from 'theme';

const StyledButton = styled.button`
    height: ${height('button')}px;
    padding: 0 ${space(2)};
    border: 0;
    background-color: ${color('primary')};
    color: ${color('white')};
`;

Compiles into...

button {
    height: 40px;
    padding: 0 16px;
    border: 0;
    background-color: #3b49df;
    color: #ffffff;
}

Conclusion

So there you have it, that's how you can setup a theme with styled-components and write it in a structured and readable manner.

I have setup a sample project in github that applies all that is written in this article for your reference. You can find it here.

You can find me on Twitter, feel free to DM me if you have questions.

Follow me on DEV and Twitter to read more frontend development tips and practices.

Stagger animations with SCSS

Jenning Ho — Sat, 11 Apr 2020 11:36:13 +0000

Overview

Staggered animations consists of a series of sequential or overlapping animations, similar to a domino effect. Staggering animations is an effective way to add flare to animating a group of items. In the context of web animation, it can be done with the help of a JS animation plugin like GSAP, or simply with CSS, depending on the requirements.

Intro

In this post I will show how we can do it with SCSS. SCSS enable us to create staggered animations with its programming like features, namely variable, for loop, and calculations.

What staggered animations is, is a series of animations that are played in sequence with a tiny delay between each elements. We will need to calculate the delay needed for each elements and apply this delay to the transition-delay or the animation-delay property. The delay needs to be less than of the duration of the animation, so that the next animation will start before the current animation ended. Ideally the delay should be between 30% to 70% of the duration for the best effect.

Scenario

Given the scenario where there are 4 elements next to each other, and we want to fade in each elements with a duration of 300ms and a delay of 100ms between each other. Here are the HTML and CSS for the effect:

<ul class="list">
  <li class="list-item">A</li>
  <li class="list-item">B</li>
  <li class="list-item">C</li>
  <li class="list-item">D</li>
</ul>

.list-item {
  opacity: 0;
  animation: fade-in 300ms ease forwards;
}

.list-item:nth-child(2) {
  animation-delay: 100ms;
}

.list-item:nth-child(3) {
  animation-delay: 200ms;
}

.list-item:nth-child(4) {
  animation-delay: 300ms;
}

@keyframes fade-in {
  to {
    opacity: 1;
  }
}

2 key points from the above code:

opacity: 0 to hide the elements before they animate.
forwards as the animation-fill-mode value so that the end frame of the animation persists. In this scenario, fade-in will bring the element's opacity to 1 and persist. Without this, element will disappear as soon as the animation ends.

SCSS

With SCSS we can achieve the same CSS output with the following code:

$n: 4;

.list-item {
  opacity: 0;
  animation: fade-in 300ms ease forwards;

  @for $x from 2 through $n {
    &:nth-child(#{$x}) {
      animation-delay: 100ms * ($x - 1);
    }
  }
}

We do a @for loop that starts from 2, and ends at 4.
Print / interpolate variable $x with #{} to append it into nth-child().
Calculate the delay by multiplying 100ms with ($x - 1).

Do note that the number of loops is dependant on the number of HTML elements to be animated. This does make the SCSS solution to be inflexible if the number of HTML elements are dynamic. So depending on your needs, SCSS might not be enough. In cases where you can safely determine the number of HTML elements, this little snippet can prove to be a valuable tool to staggering animations. Areas where I have applied this technique are such as navigation menu and cover text animations.

Formula

The formula to calculating the delay can be the key to manipulating the staggered timing to get the ideal effect. Here are a few that I find commonly applicable:

Reverse stagger

@for $x from 1 through ($n - 1) {
  &:nth-child(#{$x}) {
    animation-delay: ($n - $x) * 100ms;
  }
}

Ease-in stagger

@for $x from 2 through $n {
  &:nth-child(#{$x}) {
    animation-delay: 100ms * ($x - 1) / $x * $n;
  }
}

Ease-out stagger

@for $x from 2 through $n {
  &:nth-child(#{$x}) {
    animation-delay: 100ms * ($x - 1) / $n * $x;
  }
}

Codepen

Here's a pen to show what's discussed in this post:

Application

Here are some of my pens where this technique is applied:

Happy animating!

Masonry with CSS grid

Jenning Ho — Mon, 17 Feb 2020 11:23:20 +0000

A month ago codepen published a challenge to create a photo gallery. Oh, I know photo gallery, I've made a gallery or two, I thought. So I decided to give it a go.

What you see in the cover photo is my submission for the challenge. Thanks thecatapi.com for the amusing cat photos.

Masonry layout can be unimaginative when it comes to photo gallery (what's masonry layout?), but I had an idea to build it with CSS grid. CSS grid is powerful and you should pick it up if you haven't already. It allows you to effectively layout a webpage, but using it to build masonry layout can still be considered fairly novel. What's the secret?

There are a few key points that I'll cover:

square grid layout
varying item sizes and packing them together
content that doesn't disrupt the container size

1. Square grids

We need square grids to allow the photos to be laid out in a way that makes sense. The square grids will also need to be responsive where it will take up available space. To do that I applied a technique to size an element to specific aspect ratio. The trick is sizing an element vertically with padding as opposed to height. Percentage paddingvalue is calculated based on the element's width. i.e. equal % of width and padding-bottom will give you a square.

We don't have to apply this to every grid item (the children of a grid container). This is only applied to 1 element, the :before pseudo element of the grid container, like so:

.container:before {
  content: '';
  height: 0;
  width: 100%;
  padding-bottom: 100%;
}

This squared :before pseudo element will serve as the blueprint for all other grid item. However, this itself is not enough to generate a square grid layout yet. We will need to couple it with CSS grid's property grid-auto-rows: 1fr and grid-template-columns: repeat(var(--number-of-columns), 1fr) to form the layout.

grid-template-columns: repeat(var(--number-of-columns), 1fr) to setup the number of columns for your layout
grid-auto-rows: 1fr will force each row to be of equal size.

.container {
  display: grid;
  grid-auto-rows: 1fr;
  grid-template-columns: repeat(6, 1fr);
}

With this the grid items will be sized into squares, and will be laid out in 6 columns. This is still not the end of square grids. You'll notice that there is an empty gap at the first grid. That is the :before pseudo element taking up space. To seal this up, move both the pseudo element and the first grid item to the first block.

.container:before {
  content: '';
  height: 0;
  width: 100%;
  padding-bottom: 100%;
  grid-column: 1 / 1;
  grid-row: 1 / 1;
}

.grid-item:first-child {
  grid-column: 1 / 1;
  grid-row: 1 / 1;
}

Now your square grid layout is ready.

2. Varying item sizes and packing them together

To create the varying sizes of a masonry block, we size the grid items using grid-column: span and grid-row: span. Then we use :nth-child to simulate the randomness of a masonry layout. In my pen, I only size items up to 2 blocks, so the code looks like:

/**
  every 3rd item takes up 2 blocks horizontally (2 x 1)
**/
.grid-item:nth-child(3n) {
  grid-row: span 2;
}

/**
  every 4th and 7th item takes up only 1 block (1 x 1),
  to overwrite the previous 3n rule
**/
.grid-item:nth-child(4n),
.grid-item:nth-child(7n) {
  grid-column: span 1;
  grid-row: span 1;
}

/**
  every 5th item takes up 2 blocks vertically (1 x 2),
  also every 15th block will be a big one (2 x 2)
**/
.grid-item:nth-child(5n) {
  grid-column: span 2;
}

There are some numbers you can tweak to get the gallery to cut off perfectly, (i.e. column count vs item count), and you can tweak the numbers to get a layout that you like. There are no hard rules here. This happen to be the layout that I'm happy with.

The grid items are now seemingly sized randomly like a masonry, but there are still empty blocks scattered in between, due to the grid item not able to fit in after sizing up.

To fix that we apply grid-auto-flow: dense to pack them up. This will force the single block item squeeze into the empty blocks.

Now you'll see a respectable but empty gallery.

2. Content that doesn't disrupt the container size

To maintain the perfectly squared grid item, the content (the photos) cannot be pulling or pushing the container (the grid item itself), as that'll cause the square to collapse at the next row. We can do this by inline-styling the image url with background-image property, but that would be terrible for accessibility. So we'll do it the hard way (just kidding), by using the <img> tag and styling it with CSS.

First we want the image to not affect the container. To do that we apply position: absolute to the image and that will take it out of the document flow.

.grid-item {
  position: relative;
}

.photo {
  position: absolute;
}

Next we want to size the image so that it'll fill up the container of varying sizes. To do this we apply

.photo {
  position: absolute;
  width: 100%;
  height: 100%;
  object-fit: cover;
}

Now you get a beautifully filled up photo gallery!

Conclusion

Originally I only wanted to highlight the square grid layout technique, but figured a tutorial to build a full feldged photo gallery with css might be more interesting. There are other designs where I've applied the square grid technique too, where you need responsive squares or circles, i.e. the Olympic logo. Be creative! I hope you'll add this to your arsenal of CSS techniques!

Some related helpful resources:

Reusable @keyframes with CSS custom properties

Jenning Ho — Mon, 13 Jan 2020 11:34:30 +0000

In this article, I will share with you an application of CSS custom properties that I have found useful.

If you're like me, who like to cramp as many animations in the page as possible for micro interactions sake (just kidding, don't do that), you would be writing a lot of CSS animations with @keyframes.

@keyframes is notorious for its inflexibility, once it is declared, the values are then set in stone. If you have a set of @keyframes with the same behavior but different values, you'll need to make another set. This result in a lot of @keyframes that are similar but with a little variations in the numbers. Let’s take a look at the example below:

@keyframes fade-in {
  0% {
    opacity: 0;
  }

  100% {
    opacity: 1;
  }
}

@keyframes fade-in-a-little {
  0% {
    opacity: 0;
  }

  100% {
    opacity: 0.3;
  }
}

.item-1 {
  animation: fade-in 300ms ease;
}

.item-2 {
  animation: fade-in-a-little 300ms ease;
}

In the example above, we have 2 items with 2 different animations that are similar, with only slight difference in the opacity value at 100%.

Now imagine what this would turn into when applied to more items. As the website scale up, what you'll end up with is 100s of similar @keyframes, bloating up the CSS file. We can't have that. 😐

CSS custom properties to the rescue

CSS custom properties (also known as CSS variables), are most widely applied for theming. It can also be used to make @keyframes reusable! (If you want to learn about CSS custom properties, see here)

Let's refactor our previous example with CSS custom properties!

@keyframes fade {
  0% {
    opacity: var(--fade-start, 0);
  }

  100% {
    opacity: var(--fade-end, 1);
  }
}

.item-1 {
  animation: fade 300ms ease;
}

.item-2 {
  --fade-end: 0.3;
  animation: fade 300ms ease;
}

fade-in-a-little @keyframes is taken out as it is not needed anymore. We now have only 1 set of @keyframes fade, and apply CSS custom properties to the starting opacity value and the ending opacity value with:

opacity: var(--fade-start, 0); // start

opacity: var(--fade-end, 1); // end

In this example, we have 2 custom properties: --fade-start and --fade-end. These variables are applied using var() function (read more about it here). The var() function accepts 2 parameters, a value and a fallback (default value).

So with this line opacity: var(--fade-start, 0);, if --fade-start is not set, 0 will be applied instead. The same goes to --fade-end.

The end result we get here is a set of @keyframes that can fade between opacity: 0 and opacity: 1 by default and be tuned within the scope of a CSS selector. 🤯

Wait... so to fade out? Yes! Instead of declaring another set of @keyframes for fade-out, you can reuse fade and set --fade-start as 1, and --fade-end to 0, like so:

.item-to-fade-out {
  --fade-start: 1;
  --fade-end: 0;
  animation: fade 300ms ease;
}

With CSS custom properties, @keyframes can now be function like, where the variable parts can be defined at a later stage, making @keyframes reusable. Yay DRY ❤️️

Time to bust out the Codepen

One @keyframes to fade it all

Summary

Fading animation is one of the most common animation on the web, now with CSS custom properties we can reduce our CSS bloat significantly while having as many variations of it as we'd like.

Consider applying this to @keyframes that you find yourself repeating a lot with many little variations.

Hope you'll find this useful!

DEV Community: Jenning Ho

How I Use AI Councils to Solve Ambiguous Engineering Problems

A Practical AI Council Workflow for Software Architecture and Delivery

One AI Assistant Is Useful, But Not Always Enough

How I Stumbled Into the Workflow

The Real Insight: It Was Not About More Models

The Workflow in One Diagram

The Role Model

The Objection Ledger

Human in the Loop, But as Governor

Why I Separate Architect, Executor, and Auditor

A Lightweight Version You Can Try

Before Council

During Council

Before Implementation

Before Shipping

A Small Hypothetical Example

What This Workflow Is Not

When to Use It, and When Not To

Closing

RxJS subscription management with Angular

async pipe

async pipe used in app.component.html

first operator

take operator

takeWhile operator

takeUntil operator

takeUntil to end subscription when component is destroyed

takeUntil subscription leak

.unsubscribe()

single subscription .unsubscribe()

batch subscriptions .unsubscribe()

Conclusion

Improve your Javascript conditionals

1. Name your condition

BAD

GOOD

2. Type coercion

BAD

GOOD

BAD

GOOD

3. Guard clause

BAD

GOOD

4. Conditional operators

BAD

GOOD

5. List check

BAD

GOOD

BAD

GOOD

6. Multiple outs

BAD

GOOD

Conclusion

Animated CSS loaders

They are rearranged for better display, not sequentially ordered.

The brief

The .loader class

The dots

The animation

Conclusion

Responsive typography

media queries

clamp()

calc()

Conclusion

Resolve promises in sequence with RXJS (ConcatMap)

Organize styled-components theme in React with Functional Programming

styled-components

A button component style that will adapt its background-color based on component's prop primary.

Accessing these theme value can get messy when you have a lot of them.

Functional programming

Function currying

Function composition

Ramda

Setup

Accessors

`async pipe used in app.component.html`

`takeUntil to end subscription when component is destroyed`

`takeUntil subscription leak`

`single subscription .unsubscribe()`

`batch subscriptions .unsubscribe()`

A button component style that will adapt its `background-color` based on component's prop `primary`.