Skip to main content

3 posts tagged with "lab"

View All Tags

· One min read
info

According to this test, the 'entry' action is raised first, and then the 'always' action is raised.

import { assertEquals } from "https://deno.land/std@0.224.0/assert/mod.ts";
import { createActor, setup } from "xstate";

Deno.test("x-entry-or-always-action-raise", () => {
  const machine = setup({
    actions: {
      entry_action(_, box: string[]) {
        box.push("entry_action");
      },
      always_action(_, box: string[]) {
        box.push("always_action");
      },
    },
  }).createMachine({
    context: {
      box: [] as string[],
    },
    initial: "Start",
    output: ({ context: { box } }) => box,
    states: {
      Start: {
        always: {
          actions: {
            type: "always_action",
            params: ({ context: { box } }) => box,
          },
        },
        entry: {
          type: "entry_action",
          params: ({ context: { box } }) => box,
        },
      },
      Finish: {
        type: "final",
      },
    },
  });
  const actor = createActor(machine);
  actor.start();
  const snapshot = actor.getSnapshot();
  assertEquals(snapshot.context.box, ["entry_action", "always_action"]);
});

· 2 min read

That is what I want to play with today!

Spoiler:​


name: Deploy all target by pushing into main only
env:
  CURRENT_BRANCH: ${{ github.head_ref || github.ref_name }}
  EXPLICIT_PUSH_BRANCH: main
  IMPLICIT_DEPLOY_BRANCHES: "deploy-1 deploy-2 deploy-3"
on:
  pull_request: # will be making explicitly
    branches:
      - ${{ env.CURRENT_BRANCH }}
  push: # after PR these pushes will be triggered implicitly
    branches: [deploy-1, deploy-2, deploy-3]
jobs:
  general:
    name: General for any workflow (branch)
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: write
    steps:
      - name: show token // TODO rm
        run: echo ${{ secrets.SUPER_GITHUB_TOKEN }}

      - name: Clone repository
        uses: actions/checkout@v4
        with:
          token: ${{ secrets.SUDO_GH_TOKEN }}

      - name: Current branch
        run: echo ${{ env.CURRENT_BRANCH }}

{/*

· 5 min read

Introduction​

React offers two approaches for managing inputs: controlled and uncontrolled. Controlled inputs, where the input value is explicitly managed by React (typically using useState and handling changes with onChange()), allow for more complex scenarios and precise control. Uncontrolled inputs delegate this responsibility to the browser, resulting in a loss of fine-grained control over the component's behavior.

In React, controlled inputs are generally preferred because they integrate seamlessly with React's state management and lifecycle.

Problem​

A potential issue with controlled inputs is performance degradation. This occurs because every keystroke triggers a rerender, which can affect the performance of the component and its siblings.