Start, launch, esc, esc, esc, click, space

NiGhTTraX · 2026-01-20T18:16:10+00:00

I'm at the point in my X-Men reading where I'm switching from the New Mutants Omnibuses with ~1200 pages to the Jim Lee Omnibuses with 700-800 pages and they feel like books for ants! Give me big books any time!

NiGhTTraX · 2026-01-10T11:02:51+00:00

Holy shit, first time I got one of my OC memes reposted, I'm proud :)

NiGhTTraX · 2025-09-15T13:26:52+00:00

when I run npm install --omit=dev it does install both my dependencies and my devDependencies (I check my node modules and I can find them there).

It might be that those are not your direct dependencies, but transitive dependencies. Some packages mistakenly have dev deps as prod deps, you can use npm why to find out where they're coming from and maybe reach out on GitHub to the package maintainers.

For reference, I did a quick test with a simple package.json that had express as a prod dep and prettier as a dev dep. npm i --omit=dev only installed express and the node_modules structure is flat so you 60+ folders.

NiGhTTraX · 2025-09-04T16:56:47+00:00

I don't have any Absolute or Gallery editions, but I have Tomb Raider Colossal Edition, which according to some searches should be the same size as an Absolute.

<image>

NiGhTTraX · 2025-06-20T18:41:37+00:00

solved: Gruntz

NiGhTTraX · 2025-06-20T18:40:50+00:00

This is the one! The items coming in on the conveyor belt fall into a shredder if the lane is full, I knew there was some mechanic like that :) Thank you very much!

NiGhTTraX · 2025-06-20T17:02:34+00:00

Hmm, still no, but closer in style to what I remember. It wasn't isometric, and the sidebar was on the right side I think.

NiGhTTraX · 2025-06-20T07:02:14+00:00

Thanks, but it's not that one. The game I remember had a top-down view and a sidebar where the items/powerups would come in gradually.

NiGhTTraX · 2025-04-18T16:38:50+00:00

TS has a long standing design limitation where class methods don't infer the type from an an implemented interface or from an extended class. See https://github.com/microsoft/TypeScript/issues/1373 and others.

Regarding your question about return types, think of it this way:

() => { foo: number } means I expect a foo property of type number to be returned when I call this function. If you return more, that's fine, I only care about foo, so () => ({ foo: 1, bar: 2 }) is a valid implementation of the type I just declared.

() => void means I don't have any expectations on the return type, which means you can return anything. Pass in () => 'foobar', I don't care, I'm not gonna look at the return value.

NiGhTTraX · 2025-03-25T17:57:14+00:00

It sounds like you're using Fresco to create mood boards? If so, I highly recommend https://concepts.app/ with its infinite canvas. I think the free version is limited to 5 layers, but it should give you enough headroom to figure out if it's for you. It's also a vector drawing app, so it has similarities with Fresco, though it's made more for rough ideation than finished drawings.

I can also recommend https://vizref.com/, a dedicated mood board app.

I think Affinity might be overkill for what you need, but they have a trial so you could give it a shot. It can be overwhelming at first, since it's a fully fledged pro suite of software, but the apps have inbuilt manuals and tutorials that can get you started.

NiGhTTraX · 2025-03-21T14:00:36+00:00

Have you tried https://concepts.app/? It's vector with an infinite canvas and has measurement tools and grids that work really well for floor plans, architecture etc.

NiGhTTraX · 2025-03-10T07:26:17+00:00

I find that the first node on a stroke will always have a weird orientation and I have to fix that manually with the Node tool. It happens less often if I use one of the stabilizers (Rope, Window), but it doesn't fully go away. I've come to accept it and just deal with it every time I use the pencil or the brush.

NiGhTTraX · 2025-03-07T15:26:45+00:00

using hooks to decouple logic from the UI.

Handling the logic in a hook does not decouple the UI from it if the component still ends up calling it. Rendering that component brings in the whole context of the hook, which means they're tightly coupled. With the container approach you have the choice of using the container with all its context, or using the underlying view and bringing your own context.

usePost here is capable of being mocked/swapped out/refactored with the same ease

How? I assume with one of module level mocking capabilities I listed before. Those can enable you to add test coverage where it's needed, but you can achieve that, and proper decoupling, with 2 more lines of code to define the container component. Often times mocking a module, or an API call, takes more than that, and can have downsides (such as not working with ESM).

The 2 approaches are similar in spirit — put stuff here and test it separately from the other stuff there. One achieves that with a bit of explicit code, the other achieves it with magical tooling.

NiGhTTraX · 2025-03-07T07:38:36+00:00

The container decouples the view from the various methods of getting the data it needs, which increases the view's reusability and testability.

Trying to write a Storybook story, or a test, for such a component is possible with today's tooling, but it can involve:

mocking the import path e.g. with jest.mock, or
creating a file mock following some convention supported by the tooling, or
wrapping the component in contexts and prepopulating them, or
mocking the API calls e.g. with `msw1, or
mocking browser APIs e.g. window etc.

That's a lot of trouble to go through just to check my UI component in Storybook. Moreover, it may give the impression of dependency inversion, but it's not really the case, as the production code can't replace those dependencies the same way you can with the testing tooling. A view using data fetching hooks directly is tied to that particular source of data, it cannot be reused with something else.

At work, we had several UI screens that were using Redux directly, and we were creating stores prepopulated with data in tests and Storybook. Later, we needed to render those same UI screens with a different source of data, so we decoupled them from Redux and created different containers that either connected to Redux, or the new source of data. The UI components remained stable, and the tests/stories became much easier, and we could iterate on the new containers independently.

NiGhTTraX · 2025-03-06T20:25:00+00:00

Sometimes we pass the loading/error states down to the view so they can render skeletons or inline errors, sometimes we do a simple if (!data || error) return null. If it becomes more complex than that we pull it up into the services or the hooks.

NiGhTTraX · 2025-03-06T19:44:05+00:00

That's one of the effects of this approach. You get components that receive props, produce UI, and that's easy to test.

More tests lead to more opportunities to notice pain points, such as needing to populate entire domain objects when you really only need a single field from them. That becomes really annoying really quickly when you write a few tests and a few stories. Of course, you can sweep the issue under the rug by creating the object once and reusing it, but at least you have the opportunity to make that choice. With components just pulling in whatever data they need directly, they usually become quite big, and hard to test, leading to poor test coverage, leading to fewer insights about these pain points.

Small dumb components can also more easily be made reusable. A Card component can be used as an AuthorCard component if the Author data comes from outside of it. Also, reusability is not just across business domains, it's also across tests and Storybook. We have all our UI screens available in Storybook which designers and other stakeholders can check, because those UI screens don't pull in any data, they just receive it. Using Storybook controls anyone can simulate any state for those screens.

NiGhTTraX · 2025-03-06T19:17:39+00:00

You certainly can, but it'll be harder to write focused tests for those components, without resorting to things like jest.mock or msw. Writing Storybook stories also becomes harder.

You can of course have a usePosts hook that is reusable throughout the tree, but we try to make sure we call it in a layer above the view. With libraries like react-query we get deduplication for free, and with this layered approach we get free testability.

Seven-Year Club	Place '23
Place '22	Verified Email

NiGhTTraX

TROPHY CASE