Sungbin Jo

I’ve recently restarted my (previously abandoned) HackerNews project – huge thanks to @collindonnell’s code review. I've just released v0.1.0, the first version that is “usable”. Still has a long way to go though. Please try it out! RTs appreciated. github.com/goranmoomin/Ha…

gotta say at this point i'm just wondering how someone can just have no sense of shame AT ALL lol

Fast-forward merge for GitHub github.com/simnalamburt/f… GitHub has gone far too long without supporting fast-forward merge in the web UI, so I built it myself as a Chrome extension. Give it a try!

This is a lot more annoying when done on API documentation. Looking at Google…

One thing I can't get over with a lot of corporate blog posts is how a lot of them are LLM-translated, and then they show the translated one, with no clear button to switch to the original one. Reading the article it's pretty obvious that they don't review the translate…

@jeremyphoward @mitchellh Oh I just googled this for reference and this tweet lol More references: superuser.com/questions/2644… github.com/kovidgoyal/kit… users.rust-lang.org/t/a-strange-ph… Unfortunately last time I checked there isn’t any method to configure this size :(

@jeremyphoward @mitchellh That’s probably a macOS thing, I had the same experience in Terminal.app. It’s due to the macOS kernel only providing a tiny (1024 chars) buffer to the tty for default cooked mode. That’s why if you paste text with no new lines, it gets truncated after 1024 chars.

Anyone using Wezterm? I've been having quite a few issues with Ghostty recently (particularly with trying to paste more then a few lines of text in—it often truncates) so wondering about trying something else. I've used alacritty before, and liked it. wezterm.org

Now with the handle goranmoomin.dev on bluesky :)

Just to let everyone know, I’m more active on bluesky as goranmoomin.bsky.social

@dai_shi @TkDodo Would creating an issue in the Zustand repo actually find out a good API for this, or nah? I did notice that for Jotaiv2, there seems to be a provided AbortController that seems to prevent these scenarios: #advanced-api" target="_blank" rel="nofollow noopener">jotai.org/docs/core/atom…

@goranmoomin @TkDodo It might not be the real solution, but you can store a promise value itself. (and use `use` to consume) store = create((set) => ({ v: Promise.resolve(0), action: (a) => { set({ v: f(a) }); })

I'm trying to figure out race conditions in async actions when using Zustand… So i.e. if I have an async action that does async things before setting the store, when calling the same actions twice, the first might actually take more time than the second and set a wrong value.

@dai_shi @TkDodo Ouch would that mean that there's not really a *clean* solution for React <=18 for now?

@TkDodo @dai_shi @tan_stack For example… if you're doing web workers and you're getting asynchronous responses. (I guess one might probably able to bend over react query to actually handle it, but i'd rather not) ;)

@TkDodo @dai_shi @tan_stack I'm very grateful of react query and using it heavily, it's just that there's some kinds of async actions that aren't really data fetching… but still basically has the same problem.

Tagging people who might know *the* solution: @dai_shi @TkDodo (sry for the noise…)

i.e. if we have a store = create((set) => ({ v: 0, action: (a) => { let v = await f(a); set({ v }); }) and we do action(a1) and action(a2), then depending how much await f(a) takes, v might be set as f(a1) instead of f(a2). I'd like to prevent this, how should I do that?

When Ghostty detects a password input prompt, it now changes the cursor to a lock and on macOS enables the secure input API. When the secure input API is enabled, we show a neat, animated icon that explains what's going on when clicked. Another example of native UI wins (imo). Secure Input is the macOS system API that prevents accessibility APIs from reading your keystrokes, so things like screen recording software and so on can't read your passwords. Other terminals on macOS support secure input. I think only iTerm also supports secure input on password detection. So as a disclaimer, I'm not trying to claim this as a huge innovation, I just think our implementation is nice. 😊

@TkDodo Yeah maybe. I might just have too much resistance on creating new components and go the easy way. (I personally feel that if you have a lot of components 'for the same thing', it's harder to make the logic for that thing 'local')

@goranmoomin If that's the case, you have another natural splitting point for your component composition: the hooks + jsx after the early return should likely become their own component.

I was a bit vague, so here is a better example. There's an obvious bug in here: When you're pending, you also have no data, so you'll render the empty screen right away with the spinner. The condition needs to be !data && !isPending. Gross. Also, all conditions we add in the future must check each branch. I've seen those components evolve into huge monsters a lot, but also this rather simple flow is already hard to grasp. It's not clear to me what actually gets rendered in each "state". Cognitive load is what matters (great read btw: github.com/zakirullin/cog…) So why did we add those conditions in the first place? Well, because they all share the div and the Heading and the Card with the same styles. If that becomes it's own layout component, things will be much easier to read, because we can then use early returns: We mostly don't care about the layouting jsx, it's boilerplate, so move it away from the logic. This version doesn't have the bug. Also notice how TypeScript now helps us with type inference. Because we have returned with !data, it now knows that data is defined afterwards. If it's easier to grap for the compiler (which is pretty smart), it's surely also easier for humans to understand.

@TkDodo So at that point you’re forced to have all of those returns at the end, and so you get a bunch of logic between your data fetching logic and your returns… And at that point I feel like this starts to matter less (bc most of the complex code isn’t in JSX, but the logic above.)

@TkDodo I’ve always avoided early returns in React because I felt it doesn’t work well with hooks. If you call a hook between one of the returns, that becomes an error right (due to the rules of hooks)?

Anyone know what Apple Interface Designers use these days to “prototype” these types of interactions/effects? Assuming (other than fairy dust) Metal shaders directly, in little Swift prototypes. But curious what folks are happy to share or know.