Muhct Posts - Answer Overflow

Muhct

Explore posts from servers

KPCKevin Powell - Community TTCTheo's Typesafe Cult

Posts Comments

TTCTheo's Typesafe Cult

•Created by Muhct on 9/14/2024 in #questions

Is there a Vitest UI equivalent for Jest test suites?

2 replies

TTCTheo's Typesafe Cult

•Created by Muhct on 8/17/2024 in #questions

Is there a built-in way to prevent ID duplicates using Zod?

Let's say that your data is an array of objects with "id" and "name" fields:

[
    {
        id: 1,
        name: "Joe"
    },
    {
        id: 1,
        name: "Schmoe"
    }
]

[
    {
        id: 1,
        name: "Joe"
    },
    {
        id: 1,
        name: "Schmoe"
    }
]

as you can see, the id is duplicated but it should be unique. Does Zod have a built-in method to validate against this kind of issue? I wasn't able to find any. Or am I forced to use .refine and create a new Set with all the ids in my data?

5 replies

TTCTheo's Typesafe Cult

•Created by Muhct on 7/14/2024 in #questions

Using hardcoded data for comparison in unit tests with toEqual?

Hi there, I have a React app and I want to create a unit test for a function that removes scattered zeros inside of an array. Basically my idea is to have a src\mocks\data\IndexadorDataMock.ts file with hardcoded dirty data, and then the (also hardcoded) clean data - aka the expected output. For example:

// src\__mocks__\data\IndexadorDataMock.ts

export const itemsMockData = [
    0,
    { down: 4719, left: 4718, right: 4720, id: 1, up: 4721 },
    0,
    { down: 4723, left: 4722, right: 4724, id: 3, up: 4725 },
    0,
];

export const cleanItemsMockData = [
    { down: 4719, left: 4718, right: 4720, id: 1, up: 4721 },
    { down: 4723, left: 4722, right: 4724, id: 3, up: 4725 },
];

// src\__mocks__\data\IndexadorDataMock.ts

export const itemsMockData = [
    0,
    { down: 4719, left: 4718, right: 4720, id: 1, up: 4721 },
    0,
    { down: 4723, left: 4722, right: 4724, id: 3, up: 4725 },
    0,
];

export const cleanItemsMockData = [
    { down: 4719, left: 4718, right: 4720, id: 1, up: 4721 },
    { down: 4723, left: 4722, right: 4724, id: 3, up: 4725 },
];

And then my test file Helpers.test.ts:

describe('Helpers', () => {
    test('removes scattered zeros using cleanIndices', () => {
        const result = Helpers.cleanIndices(itemsMockData);
        expect(result).toEqual(cleanItemsMockData);
    });
});

describe('Helpers', () => {
    test('removes scattered zeros using cleanIndices', () => {
        const result = Helpers.cleanIndices(itemsMockData);
        expect(result).toEqual(cleanItemsMockData);
    });
});

My question is: is this a common practice for React projects? By "this" I mean having a separate file with very long, hardcoded data that you'll use for .toEqual comparisons in your tests

8 replies

TTCTheo's Typesafe Cult

•Created by Muhct on 6/22/2024 in #questions

Best practices for rendering the version of your app

I have a React-TypeScript web app in which I'd like to render the current version at the top of the home page. What I'm thinking is that I could have a version.ts file with this:

export const APP_VERSION = "1.0.0"

export const APP_VERSION = "1.0.0"

and then when I make a commit, I increase that number. But I've never seen this being done in real world open source github projects. What's the best approach here?

14 replies

TTCTheo's Typesafe Cult

•Created by Muhct on 6/20/2024 in #questions

Best practices for typing a reusable button?

I have a React-TypeScript-Material UI app with a Button component but I'm not sure if what I'm doing is a good practice. Basically in the ButtonProps 4 out of 5 props are optional. Is this ok or should I structure the code in a different way? Perhaps not turning the button into a reusable component at all?

// src\components\shared\Button.tsx
/** @jsxImportSource @emotion/react */
import React, { ReactElement } from 'react';
import { css } from '@emotion/react';

type ButtonProps = {
    children: string;
    leftIcon?: ReactElement<SVGSVGElement>;
    onClick?: () => void;
    disabled?: boolean;
    'data-testid'?: string;
};

const styles = (leftIcon: ReactElement<SVGSVGElement> | undefined) => css`
    position: relative;
    border-radius: 8px;
    border: 2px solid transparent;
    padding: ${leftIcon ? '0.6em 1em 0.6em 0.8em' : '0.5em 1.2em 0.6em 1.2em'};
`;

const iconContainerStyle = css`
    // more styling
`;

export const Button = ({
    children,
    leftIcon,
    onClick,
    disabled,
    'data-testid': testId
}: ButtonProps) => {
    return (
        <button
            css={styles(leftIcon)}
            onClick={onClick}
            disabled={disabled}
            data-testid={testId}
        >
            {leftIcon && <span css={iconContainerStyle}>{leftIcon}</span>}
            {children}
        </button>
    );
};

// src\components\shared\Button.tsx
/** @jsxImportSource @emotion/react */
import React, { ReactElement } from 'react';
import { css } from '@emotion/react';

type ButtonProps = {
    children: string;
    leftIcon?: ReactElement<SVGSVGElement>;
    onClick?: () => void;
    disabled?: boolean;
    'data-testid'?: string;
};

const styles = (leftIcon: ReactElement<SVGSVGElement> | undefined) => css`
    position: relative;
    border-radius: 8px;
    border: 2px solid transparent;
    padding: ${leftIcon ? '0.6em 1em 0.6em 0.8em' : '0.5em 1.2em 0.6em 1.2em'};
`;

const iconContainerStyle = css`
    // more styling
`;

export const Button = ({
    children,
    leftIcon,
    onClick,
    disabled,
    'data-testid': testId
}: ButtonProps) => {
    return (
        <button
            css={styles(leftIcon)}
            onClick={onClick}
            disabled={disabled}
            data-testid={testId}
        >
            {leftIcon && <span css={iconContainerStyle}>{leftIcon}</span>}
            {children}
        </button>
    );
};

6 replies

TTCTheo's Typesafe Cult

•Created by Muhct on 11/3/2023 in #questions

Improving accessibility of a Card component

2 replies

TTCTheo's Typesafe Cult

•Created by Muhct on 6/29/2023 in #questions

Sizes prop in the <Image/> component

I've always been using the <Image> component with the fill prop, but I've never used the sizes one: https://nextjs.org/docs/pages/api-reference/components/image#sizes I'm reading the docs and I don't understand what it does. I thought NextJS Images were automatically served with the proper size according to the device of the user, was I wrong? Is the sizes prop the thing that takes care of that? As an example, I have a hero image that always takes up the whole screen width, I've added the sizes prop like this:

<Image
      src="/example.png"
      fill
      sizes="100vw"
    />

<Image
      src="/example.png"
      fill
      sizes="100vw"
    />

and I don't see any difference when it comes to the srcset of images when I inspect the element - or any difference in lighthouse (with or without the sizes prop, the amount of KB spent on images is the same) so I'm not sure what it's actually doing

5 replies

TTCTheo's Typesafe Cult

•Created by Muhct on 3/3/2023 in #questions

Serverless and price of DDoS attacks

There's one thing in serverless that I'm not able to figure out: as far as I know if you suffer a DDoS attack in AWS then you have to pay for all the usage that the DDoS attack has caused, which can get very pricey. Other non-serverless hosting companies dont have this issue: if you suffer a DDoS attack you dont get charged an extra amount. Does that simply not exist in serverless? How do you tackle DDoS attacks for your apps in serverless? A rate limiter wouldnt be enough, right?

3 replies

TTCTheo's Typesafe Cult

•Created by Muhct on 12/26/2022 in #questions

Prevent DesktopHeader from loading on network tab

1 replies

Gaming

Programming