budokans / personal-site Goto Github PK

Currently, we have two state variables and a constant variable. If we use a sum type like an Option, we only need one.

The issue that caused #82 was fixed and made it into the v1.85 release.

An overflowX prop was written as overFlowX and there was no compilation error due to Chakra UI's allowing Props to extend object on ChakraComponent.

I can't remember what the initial reason for storing data in JSON was, but it's safe to say that it's not providing any benefits now and won't in the foreseeable future. Storing it in JavaScript (well, TypeScript) objects would:

1. Improve type safety
2. Remove the need for the io-ts dependency as we won't need run-time type-checking

Furthermore, project data doesn't need to be returned in getStaticProps as the Feature components that use it aren't included in the HTML that is rendered at build time.

A fixed-value margin-top on the Portfolio component is the cause of this.

The "clicking a <Portfolio.Item /> renders the relevant <FeatureContainer />" test in the integration directory fails intermittently when expect(el).not.toBeInTheDocument() runs before the DOM element is removed.

The default duration for a Framer Motion transition is 250ms (durations aren't explicitly set in the Variants passed to the Feature component), so this is the likely culprit.

1. Feature border isn't showing. A couple of problems: it's not possible to reference a Chakra theme variable in a CSS property. Also, "grey" should be spelled gray. Also, include all style props on the MotionBox and get rid of the redundant child Box.
2. The CarouselDesktop item borders are an ugly black. Lighten the color.

The ChildrenProps type should probably be renamed to OptionalChildrenProps.

Two animations are clunky on extralarge viewports and possibly smaller viewports on machines with low RAM:

1. Feature visible/hidden
2. Draging of CarouselDesktop and initial hidden -> visible.
3. The Feature exit animation leaves a little of the Feature component visible at the bottom of the viewport before it's removed from the DOM.

A few things will probably help:

1. Remove the blur filter on the background. The animation is so fast that there's no real benefit in keeping it.
2. Ditch the opacity transition on the overlay.
3. Don't use a spring exit animation for the filter - that's the probable cause of the visible top part of the Feature on exit.

It would be good if our test suite could be run during a pull request to the main branch and before deploying to a staging environment.

Currently the test suite is small enough (takes ~20s) that we can just run the entire thing.

The current method of storing description data leaves much to be desired regarding UI rendering possibilities.

Current issues:

1. Limited to paragraphs only (no support for lists, code blocks, etc.)
2. The strings must be parsed as HTML, which adds a dependency

It would be much better if the description field references a React component that renders the description with the appropriate TSX markup.

This is due to the passing of a Regex to getByText. Define the test project first and pass references to project fields to matcher functions.

1. Font sizes are too small on smaller viewports. A minimum of 16px would work.
2. The Portfolio subheadings should ideally not be cut off at any viewport size.

Set flex-wrap: wrap on the flex element, and add a gap instead of awkwardly applying margins to all but the first child.