wingspan

It’s worse than that, since you can’t use CSS variables inside a media query!

> “And Knosso whatever-his-name was a physicist. That’s the Library of Nothing.”

> “Nothing?”

> The old woman had her spiel ready. “Physicists long since determined that most of space was empty, and most of each atom was empty, so that the overwhelming nature of the universe is nothingness, with tiny interruptions that contain all of existence. So their library is named for this Nothing that comprises most of the universe. And the mathematicians share the space, because they are proud to say that what they study is even less real than what the physicists study, so their portion is called the Library of Less than Nothing.”

> Rigg decided he was going to like the physicists. It seemed to him, though, that the mathematicians must have an annoying competitive streak.

Pathfinder (2010) by Orson Scott Card

Also a good lesson about including screenshots in any PR with UI changes. Once the maintainer saw the changes visually they were much more willing to iterate and get the PR merged.

I was able to reproduce this in a simple example [1]. If you refresh it a few times you will be able to see it flash (at least I did in Chrome on Mac). It is probably more noticeable if you set it up as an SPA with a page transition, but I wanted to keep the example simple.

[1] https://codesandbox.io/s/recursing-glitter-h4c83u?file=/src/...

I love this approach and have used it many times in JavaScript. I often end up adding an additional map in front with the resolved values to check first, because awaiting or then'ing a Promise always means you will wait until the next microtask for the value, instead of getting it immediately. With a framework like React, this means you'll have a flash of missing content even when it is already cached.

Nice! I put together a single file offline HTML version [1] with a demo [2] using only a CDN-hosted QR library.

[1] https://gist.github.com/ianobermiller/9f17f1022bc75c2228d742... [2] https://bl.ocks.org/ianobermiller/raw/9f17f1022bc75c2228d742...

Thanks for calling out that this was inspired by CodeFlow, I kept thinking that as I was reading. Still one of my favorite code review tools, used ~2012.

One of my favorite features was a panel with every comment on the PR, sorted and organized by status. Because all files in the PR were preloaded clicking a comment instantly took you to the specific code and version. So good!

Using thin-backend has been one of the most delightful experiences I've had making an SPA with a simple backend. The developer experience with the generated TypeScript types is particularly great, the DB migrations remind me of Prisma, and knowing I have a standard Postgres db under the hood is comforting. It isn't a large or complex app, but Marc has been super responsive to bugs and feature suggestions so it has been fun to iterate on. You can find the code at https://github.com/ianobermiller/colorcal.

This is fantastic, wish I had it before we had our fourth and final child. One piece of feedback: when I use the app with my thumb, the natural position for it to rest is right over the name. Consider moving the name more towards the center or top of the screen and making it possible to swipe anywhere in the top yellow area.

The problem is that TypeScript does not scale to the size of the giant monorepo at Facebook, with hundreds of thousands, if not millions of files. Since they aren't organized into packages, it is just one giant flat namespace (any JS file can import any other JS file by the filename). It is pretty amazing to change a core file and see type errors across the entire codebase in a few seconds. The main way to scale in TypeScript is Project References, which don't work when you haven't separated your code into packages. (Worked at Facebook until June 2021).

Really neat! I whipped up a single file HTML version [1] with a demo [2] using only a CDN-hosted QR library. Thanks for the distraction!

[1] https://gist.github.com/ianobermiller/9f17f1022bc75c2228d742...

[2] https://bl.ocks.org/ianobermiller/raw/9f17f1022bc75c2228d742...

You joke, but this is basically how Facebook uses MySQL for the main user table and for the majority of Entities: https://blog.yugabyte.com/facebooks-user-db-is-it-sql-or-nos...

Regarding Mosh and control mode, Eternal Terminal https://mistertea.github.io/EternalTCP/ provides the same resumable session, and works flawlessly with tmux control mode.

Fantastic, thank you for making me laugh so much. Almost makes up for the years spent being tortured by CSS just so I could appreciate your tale.

Absolutely! It is really hard to write idiomatic code your first time through with a framework. No need to feel silly at all. No way I would have spotted these things if I hadn't been using React every day for the past year or so!

Because if you are doing React and JSX you are already using JSTransform. If it gets you most of what you need, why add another dependency?

Not a bad idea. We would typically use _onClick for any component handler methods, so the _ would distinguish it. We have an internal transform that mangles anything in a module starting with _ so that it cannot be accessed outside.

Thanks for putting this together, always interesting to see people use React for the first time! I did a code review of sorts and cleaned up the code to be more idiomatic React. You can find the series of commits with in-depth comments on GitHub [1]. I may even write this up as a blog post on my website [2].

In short:

- Don't pass around components and call methods on them; prefer to pass props instead

- Conditional rendering instead of hiding, exactly as [3]

- Use the JSX harmony transforms

- Declare props

- Use classSet

- setState only needs to include props that change, rest stay the same

[1] https://github.com/ianobermiller/reactexperiment/commits/

[2] http://ianobermiller.com

[3] https://news.ycombinator.com/item?id=8247422

In case anyone is looking for this: https://nicolasamiot.wordpress.com/2013/07/25/inkscape-nativ...

Missing from this great guide was any mention of moss, an issue I never thought about until moving to the Pacific Northwest. Now my lawn is mostly moss with some grass sticking through. I have resigned to just let it grow, since it is soft underfoot and nice and green. Any tips for a mossy lawn?

Missing from this great guide was any mention of moss, an issue I never thought about until moving to the Pacific Northwest. Now my lawn is mostly moss with some grass sticking through. I have resigned to just let it grow, since it is soft underfoot and nice and green. Any tips for a mossy lawn?

I meant to mention this; the helper mixin I was referring to is called StateFromStore, and it fetches data from stores and shoves it into state via setState.

I didn't develop React, I just use it at Facebook. I started Javascript development at Microsoft where we were using mostly our own homegrown stack on www.so.cl. When I moved to Facebook, the entire project I'm working on is in React. Since I haven't built many single page apps in my spare time, I have had very little exposure to Backbone. Rest assured the React devs certainly are familiar with most of the Javascript frameworks out there ;)

Sure, that is absolutely a valid scenario. This could be accomplished using a context object as I explained in my first comment, something like {changedFields: ['isFavorite'], error: 'some error message'}. You'd then have some store that listens for article update failures and saves the error message somewhere, and then your favorite button view would pull the data from there.

The importance of keeping actions fire-and-forget is that data must live in the store; if actions have callbacks, the views would be using state to keep themselves updated with data that should be in the store.

Ah of course, I was reading it wrong. Thanks.

That's about right. We really only use state for transient display properties, mostly toggling display of some component.

Ah right, I thought so. So as long as @hcarvalhoalves is using a recent version they should be fine.

I believe the latest version of React does autobinding on component methods, so you shouldn't need .bind(this). There should be a warning letting you know this (unless it is different for the public version :/).

We split out data mutations from data access (see https://news.ycombinator.com/item?id=7721542). One reason is that multiple stores may be interested in the COMPLETE calls. One example is when you have a store that tracks which items in a list are selected; if one of the item is deleted, this separate store, say ArticleSelectionStore, needs to handle the ARTICLE_DELETE_COMPLETED event to unselect that article.

No! Never access the DOM directly if you can help it. I forgot to mention, display things like you said are one of the only places we really use local state. A dropdown for instance, might have a state called "isOpen". In your click handler, you'd call this.setState({isOpen: true}), and in render, you'd only render the dropdown if isOpen is true.