jamesknelson

Yeah, this is definitely a thing. I'm a bit conflicted over it.

One one hand, staying within the world of React components gives you a lot of functionality for free. And with Suspense and Hooks, the amount you can do within a component has become even greater.

On the other hand, there are still things that you can't do within a component. For example, you can't easily run an async function once when the component mounts - which in my opinion, would be the perfect way to fetch data.

I've been building Navi to try and create a more natural way to map routes to views and a stream of data. The thing is, the more edge cases you cover, the closer it becomes to just building React from scratch.

At this point I still think that routing and data fetching is better handled externally from React, but it's less clear cut than it used to be.

This is a nice and simple solution! Just keep in mind that it'll interact badly with the browser's scroll-to-hash functionality.

A full solution is a little more tricky, and probably involves code on multiple components:

- You'll need something to scroll to the top or the current hash on load - You'll also need code on <Link> components to check if they link to the current URL/hash, and if they're pointing to the current hash, you'll need to scroll to it on click.

Here's some relevant scroll management code from Navi's components:

- https://github.com/frontarm/navi/blob/master/packages/react-...

- https://github.com/frontarm/navi/blob/master/packages/react-...

I ran into many of the same issues as you, and open-sourced my solution (called Navi). Responding to a few of your pain points:

* Relative links are supported out of the box. If you use '..', it is relative to the current "directory" (i.e. it ignores any trailing slash)

* Navi allows you to reload the current route using `navigation.refresh()`. This is undocumented as I didn't realize that it is a feature people actually need, although I'd be happy to document it in a future release after making sure that the behavior makes sense.

* Navi handles scroll-to-hash and scroll-to-top automatically (and you can disable it by passing a prop)

* The <Link> component works for external links automatically.

* Navigating to the same page does not reload the page, but you could implement this by creating a wrapper around <Link>, and calling `navigation.refresh()` if the link points to the current page.

And while it's not specifically one of your pain points, Navi also works server-side and has an in-built static build tool for SEO – which is probably important given the features that you're looking for.

While it's easy to say "just don't do client-side routing", there are a growing number of sites where client-side routing makes sense. I saw that you're making a music site, and client-side routing definitely makes sense. I'm building content for teaching React/Frontend Dev, and the live editor loads a lot of files that should be cached between pages, so client side routing also makes sense (and besides, it's just so much faster).

Would love to hear any feedback on the tool :-) Here's the URL: https://frontarm.com/navi/en/

Seems that way. The program director is on the stream right now saying "Everything happened perfectly, almost right down to the second".

It's pretty amazing watching this. I've been following this company since when I was in high school, before their first (failed) launch. However many years later, they're one step away from actually launching humans.

Can't wait to see them launch people later this year!

Now that hooks are out I'm seeing a lot of people ask whether it's worth learning a new API for. So in this article I've asked: is any part of hooks just obviously better, even when just starting out?

My answer is that useContext() is pretty great. Would be keen to hear what aspects the rest of you have found that are just immediately and obviously better!

There are a few reasons, for example:

- You can eject (which gives you more control)

- There’s a lot less configuration involved

- It’s easier to integrate with the rest of the react ecosystem, as Navi is just a small library

- You can bolt this on to an existing create-react-app project

Yeah, I really do like this way of doing it. I might change the Vue example to do that. For React though, the HTML is usually empty, so it ends up hiding the dependencies within a tab that nobody looks at, so imports are a lot clearer.

Perhaps I could find a way to transform imports into script statements in the exported file. I'll have a think about it...

Ahhh makes sense.

Demoboard is really made for throwing together a demo as quick as possible. But I think https://codesandbox.io would suit what you want perfectly. Have you given it a try?

The Vue example actually loads Vue in index.js as an import statement. I'm not really familiar with Vue, so maybe that isn't typical and I should put it as a script tag?

Thanks :-) By "format", do you mean something like Prettier? I'm curious what tool you'd use for CSS?

Yep! Uses mdx-js to turn Markdown into JSX, and then fetches any NPM packages from UNPKG.

I wrote up an introduction with some details at https://frontarm.com/articles/announcing-demoboard/

Thanks for letting me know! I had tested it in Chrome's mobile simulator, and checked that it loaded on my phone, but hadn't actually tried scrolling. Will see if I can find a fix.

I'm kinda surprised that it works on phones at all - I'd really only been targeting browsers (because you don't usually do much coding on a phone), but other than the scroll issue it seems to work pretty well.

I’m not sure if Swiss fine machinery is the best example here. What is it about the nature of Switzerland that makes it a more natural place to create fine machinery then anywhere else?

Similarly, using American corn as an example of how free trade should work is pretty underhanded. There’s a ridiculous amount of subsidies there, and the US doesn’t have any qualms with dumping the resulting product on international markets.

This is a really interesting point. And to be honest, I don't even really mind that I'm being shown ads after purchasing a subscription. The thing is, the ads have to be in good taste.

When I was searching for a way to disable the video ads, somebody made the point that the New York Times' business model has involved showing ads to subscribers for longer than I've been alive. The difference is, those ads didn't move around the page and start screaming at you.

Like most things, there's a sensible middle ground here. Show people with buying power ads, but don't drive those people away with your desperation.

Author here, glad people seem to have found this one useful and would be happy to answer any questions!

It actually has first class server rendering support! The linked website is statically generated, with the app bundle that enables live editing downloaded afterward.

Unfortunately you still need to configure Webpack to make it work though.

Author here! This project came from me wanting to be able to extend Markdown with things like sidebars and live code examples. I've also found that it integrates better with React than similar projects, allowing for things like `pushState` links or customised rendering of headings.

This is really encouraging. The one thing that I'm not sure how I'd go about though is finding an editor. How did you go about that?

Reading this thread has been an interesting opportunity for introspection. A number of people on both sides have made very valid points. In particular, your description of the atmosphere on the inside makes the whole thing quite a lot easier to accept, and even get behind.

With this said, I think I've also come to understand more about why instinctively I feel a little uncomfortable. It is because as a foreigner who would love to work for SpaceX, I don't feel I can - because it is nigh impossible in this day and age to become American without some decent amount of wealth. If it wasn't for ITAR, I think the chant would be less uncomfortable, because it would be less exclusionary.

That said, I don't think you or other Americans should give a rats about what randoms on HN think. We're just jealous of your opportunity to be part of history. Don't feel guilty about having an opportunity, but instead do your best with it. And if that means chanting USA, then do it without any second thoughts!

I like how you put "you could theoretically build a car from scratch". As someone who writes about and uses React daily, and have written things from scratch before, that strikes me as a really good way of explaining the utility of frameworks to newcomers.

While most apps with any complexity will end up using some sort of framework, there is no rule which says it has to be an existing one. In my experience, a lot of the more involved projects I've worked on have used their own custom framework (as opposed to React, Angular, etc.) The upshot of this is that it is certainly possible to build something worth talking about without using one of the popular frameworks.

That depends on what you mean by "great service". As an Australian living in Japan, I was unfamiliar with tipping until a recent trip to the US. And the thing that surprised me even more than the bizarre idea of me having the power to underpay a worker despite them doing a perfectly good job (that would be illegal in other countries), would be the idea of "great service". Apparently in the US, great service consists of being nagged constantly to remind you that he server exists and needs a tip. Great sevice in Japan however means leave me the fuck alone and let me enjoy my meal in peace.

Author here. My target audience here was really people who've already decided they're going to use React, and are keen on understanding what is going on under the hood. And while I do love JSX (and use it in my own projects), my feeling is that to really grok React, writing something without JSX is invaluable.

Thanks for letting me know about the broken Firefox examples! They should be fixed now.

I agree, you'd never want to actually build something this small with React - Vanilla DOM manipulation would make a lot more sense. That said, React does make sense for larger applications - and my intention is to write a series which will take you from not knowing React to being able to use it for an appropriately sized app. This is just part of the road there :)

I see myself as a UX Generalist.

I've been doing freelance development as a solo developer for a number of years now, and this entails doing everything from interviewing users, gathering requirements, building the actual product, and then iterating based on user feedback. My reasoning for seeing my role as a "UX generalist", as opposed to a "JavaScript generalist" or "full-stack engineer" is that it feels like in this role, development comes second to actually providing the customer with the best experience.

I'd love to hear what words other people would use for the same role!

I've got the same problem with finding decent content in Aozora Bunko. For me, the main issue is how to find content which matches my level (actually being interesting being the other problem, but seemingly harder to solve).

I set up a really hacky "grader" algorithm and run it on a bunch of the Aozora Bunko books, then put them online [1]. The very "easiest" books are kinda boring, but it is certainly easier finding usable material in that list than looking in Aozora Bunko itself. The one I've found most interesting so far is 銀河鉄道の夜 [2]

[1] http://www.readyourgrade.com/

[2] http://www.aozora.gr.jp/cards/000081/files/43737_19215.html

Compared to Japanese, "I have in Berlin been" almost sounds natural.

In Japanese, you'd say "Berlin ni ita", or translating rather literally, "Berlin in was". You'd omit the "I", which can lead to some interesting misunderstandings.

Needless to say, Google translate borders on useless here.

To focus on being "crispy", i.e. short and to the point. Can't find a blog about it, but she wrote about it in "Just Fucking Ship": https://unicornfree.com/just-fucking-ship

One thing that weirded me out about Japanese supermarkets is that the Australian beef I've found is totally inferior to any of the Australian beef I've seen in Australia. I wonder if preferences are different?

Quitting certainly is the ethical thing to do. I wonder if I'd quit if I was in their position.

Handing your concerns to management in writing isn't really a done thing in this culture. I sometimes get laughed at for even suggesting it. And people who quit often take a massive pay cut, are forced into contract work with no safety, or even don't ever get hired in software again - especially in Nagoya where everyone seems to knows everyone.

And when you have a family and a mortgage to pay (selling a house here is also a guaranteed massive loss), it can realistically be a choice between you and your family on the street or doing what you're told.

While the engineers aren't blameless, the system over here is really broken.

While I can't say for sure where I'll be 30 years from now, I feel like it is better to dream big than to give up while I'm still young. With that in mind, I'd love to be helping to get us off of this rock before we accidentally sterilise it - even better if I can do so before 30 years passes.