I don't think it's fair to say React hooks are optimising for writability, even if they are much shorter, but modularity. While lifecycle methods are 'obvious and straightforward', they often spread related functionality across multiple different functions, which can be more easily grouped together with hooks. And if you have similar lifecycle-based functionality that needs to be shared between multiple components, you end up with a variety of not-great solutions, whereas that is simple with hooks.

That's not to say hooks aren't without a downside, it is more to learn, with a different mental model, and their own edge cases. But having used hooks exclusively for a larger project, I couldn't imagine going back to lifecycle methods.

All of these discussions seems to forget that React hooks is two different things combined: (1) it's a new magic way of having stateful components and (2) it's a new set of APIs. I don't quite see why they _have_ to be so coupled. Wouldn't this be possible as well?

    class Chart extends Component {
      constructor(props) {
        super(props)
        this.useEffect(() => {
          const newData = getDataWithinRange(dateRange)
          this.setState({data: newData})
        }, () => this.props.dateRange);
      }
    }

You're not able to completely mirror the API (e.g. here the dependencies has to be a function), but you would get code which behaves very similar without the weird hook API. I'm sure these APIs would have various gotchas in order to be used correct, but it's not like React hooks is gotcha-free at all.

Interestingly, useMemo doesn't even need to be defined in React in a class-based component:

    function useMemo(f, dep) {
      let prev;
      let value;
      return function() {
        let next = dep();
        if (next !== prev) {
          prev = next;
          value = f();
        }
        return value;
      }
    }

    class Chart extends Component {
      data = useMemo(
        () => getDataWithinRange(this.props.dateRange),
        () => this.props.dateRange)
      )
    }

This is also just one of the possible APIs. I'm sure there are variants of this which are more performant and/or easier to work with.

Would it be _possible_ to implement hooks as part of classes? Sure, it's just software, code can implement basically anything.

But, the React team deliberately opted to only implement hooks for function components for a few reasons:

- Function components didn't have capability parity with class components in terms of having state and side effects

- Class components already had the ability to do this kind of functionality overall

- Long-term, function components are easier for React to deal with for things like hot reloading and the upcoming Concurrent Mode. By dangling a carrot to convince folks to move to function components + hooks, it becomes easier to implement that functionality for the React team.

Personally, beyond development, I haven't found rollback migrations particularly useful. Once you've run migrations on a live database, it's often much simpler operationally to treat any rollback as a new migration, to keep things append-only.

From that perspective, while rollbacks are nice, the technical investment needed to auto-generate sound rollbacks for all DDL operations is probably vastly outsized compared to the benefit, so I can see why it wouldn't be a high priority, especially if targeting multiple databases. If you're writing things by hand, there's not a whole lot of difference between the two.

That's fair. It never occurred to me honestly, but it's reasonable - especially since I don't think humans can reliably make `down.sql`

Those down files probably rarely receive as much implicit or explicit testing as the up files, too. I sure wouldn't trust them, in most cases.

Sheetless | TypeScript Engineer | https://sheetless.io | London, UK | Full-time | REMOTE

Sheetless is creating an IDE for simulations, helping people to move their knowledge about the systems they know out of their heads and spreadsheets, and into a more helpful tool. We're making it easier for people to understand systems and make better decisions to improve them, whether that's a business, or the environment.

We're a SaaS product, developing using TypeScript/Rust languages. On the frontend we're using a stack of React/Redux/Next.js/Material UI, along with some Rust modules powering the simulations. As one of our first hires, we're looking for someone comfortable and capable to build out new UI/UX around building simulations, with a focus on making things accessible for non-experts.

We're early stage, with initial funding and eager first customers. We're fully remote, but being within a couple of timezones of the UK is preferred.

If you're interested, you can find a full job description and contact details at https://sheetless.io/careers

1 round doesn't give a very good layout, 8-10 rounds seems to be enough for a good layout most of the time

This doesn't seem to have been updated in a year. How does this compare to other projects such as https://github.com/jsverify/jsverify which are currently more active?

Postgres used to have timetravel built in, but there's still a basic timetravel implementation in the contrib: http://www.postgresql.org/docs/9.4/static/contrib-spi.html

Looks good, just giving a shot at integrating. On the API, it would be great if your events API would accept a user-agent string, would make generating events on the server easier, and lighten the JS blob for clients.

"awesome" lists are rather common, there's even a meta-awesome list of them:

https://github.com/sindresorhus/awesome

There is also the meta list at https://github.com/bayandin/awesome-awesomeness which is popular as well.

And even a List of Lists of Github Lists https://github.com/yaph/lologl (shameless plug)

Relay looks like it will partially replace Flux if you're using it to manage the client<->server state, but Flux still seems necessary if you have a lot of intra-client state to manage (such as in a document-editing SPA).

Is there much benefit in using Phoenix for the server for a SPA where 95% is API routes, over using Plug directly? I guess it might make adding websocket services easier in future? (I've been very impressed with Plug/Ecto, just wondering if moving over to Phoenix while not too entrenched would be worthwhile.)

Even if you aren't using Channels or HTML views, you still get the nice features like Router pipelines, JSON Views, code reloading in development for "Refresh Driven Dev", and our Controllers, which provides a number of nice features on to of Plug, like content negotiation. Phoenix Views are really nice for JSON composition and if you ever need to start serving other content like HTML, you'll be all set. Plug is a fine choice, but you'll have to roll a lot more code yourself. If are planning WS related features in the future, Phoenix will make that a first-class experience, where Plug you'll have to dip directly into the underlying webserver adapter.

Thanks, that's useful, I'll take a look at moving across.