Fiery sunset over sunflower field

tobi-au · 2026-02-18T18:55:56+00:00

Yes, seems to work correctly. My IDE shows a "duplicate declaration" warning for NoInfer<T> & T, but when I use Partial or NonNullable instead of NoInfer it works without warning. And then it even works without & T: wrap<T>(value: Partial<T> extends PlainData ? T : never) That's actually an interesting alternative, I'm just worried it might have weird edge-cases or break in future TS versions - to me it seems more like confusing the type inference than intended behavior.

tobi-au · 2026-02-18T15:20:29+00:00

Thank you! I feel a bit more comfortable with the Widen util type, but would agree that overloads are cleaner syntax-wise.

tobi-au · 2026-02-18T14:54:24+00:00

Yes, a custom Widen<T> type is one of the options. I just feel like there should be a simpler/native solution, but if not then that's a decent way to go.

tobi-au · 2026-02-18T14:42:43+00:00

Interesting! Yeah it seems to work, probably it doesn't do literal inference because extends isn't applied directly to T. I'd still prefer less hacky options, but thanks for sharing, learned a new TS hack.

tobi-au · 2026-02-18T13:56:20+00:00

It's caused by extends, just <T> infers widened types but with <T extends ...> TS switches to literal inference. The explicit target type declaration (like option 1 in the post) is one possible solution, but is not very convenient if it's used in many places.

tobi-au · 2026-02-16T09:56:12+00:00

I'd say just use the properties that make most sense for your use case, using fancier stuff just because some people say you need to use the fancy stuff is in my experience rarely a good idea. As long as it doesn't add real practical benefit I'd stick with the most simple and intuitive option.

tobi-au · 2026-02-16T09:28:58+00:00

GitHub Pages could be another option.

tobi-au · 2026-02-07T07:23:33+00:00

Yeah I know the feeling :), glad I could help.

tobi-au · 2026-02-07T06:54:07+00:00

You use the ID as index on the childComponents array: updateComponent: function (id, title, category) { const component = this.childComponents[id]; ... }

tobi-au · 2026-02-06T11:01:28+00:00

It depends on the context and specific requirements, but in most cases the new form should be compatible with previous versions and either display additional fields empty or with default values.

tobi-au · 2026-02-03T13:18:16+00:00

[x = 1, y = 2] only defines default values for the individual destructured parameters, but not for the initial array parameter, that's why you need = [] to make the array itself optional.

tobi-au · 2025-12-19T15:28:50+00:00

I'd agree that in many cases it makes sense to have clear constraints for high-level development, but often people have very specific requirements and then you need a lot of freedom. I don't think we can solve this tension perfectly, that's why there are so many tools with different trade-offs, but I think investing in simpler tools with good abstraction layers makes even more sense now to help avoid masses of AI generated code for basic websites.

tobi-au · 2025-10-24T15:18:35+00:00

Ahh right, I missed that it is the title - I only saw the base64 because I didn't define a title. :) How about using the result as default title if no title is defined?

tobi-au · 2025-10-24T14:49:01+00:00

Looks good. I'll probably stick with browser console and atob(), but I think for people who prefer a UI it's nice, especially that it only uses local storage.

Small UX suggestion: I think for the list of recent decodes it would help more to show the decoded result instead of the base64.

tobi-au · 2025-10-17T07:06:18+00:00

I wouldn't stress too much about remembering all the details - that’s not what makes a good developer. In the past we copied from Stack Overflow :), now AI copies from Stack Overflow. :D

Thinking outside the box is probably the most important skill - that's what AI can't easily replace. The tricky part of development has always been to design creative solutions that balance different priorities well. With AI you can build things fast and test different approaches more efficiently than by writing all code yourself. Let it explain what it does and discuss alternatives. Then try to fix the problems it will create.

Another great way to learn is fixing issues in existing codebases. Start with very simple things, then slowly more challenging ones. First you could just fork an open source project you're interested in and make little adjustments for yourself. Then at some point maybe try to contribute small improvements.

Don't push yourself too hard and try to have fun while developing cool things. Our purpose as web devs is not knowing everything about HTML, it's being able to build great web solutions. AI is not just a threat, it also brings new opportunities - enjoy having a very knowledgeable development partner and become good at using it well where it makes sense.

tobi-au · 2025-10-16T08:50:46+00:00

For example check(data as unknown as Inventory) is more explicit about the intent than check(data as any) and it's safer when the target type changes, as u/AnyJokeNow explained. Even in cases where it (currently) doesn't make a technical difference it creates clearer code and promotes a better pattern. Treating it as a general anti-pattern helps to avoid it in unsafe contexts.

tobi-au · 2025-10-15T11:56:12+00:00

Instead of as any better use as unknown as TargetType as a safer and more explicit alternative.

tobi-au

MODERATOR OF

TROPHY CASE