drabinowitz

Yeah if I have multiple terraform projects in one repo it would be helpful to have a UI show deployments for each project with a list of rollouts so I can see which one I want to go back to. For SREs it might not be as helpful but if you delegate some scoped terraform module creation to the developers themselves it’d help them to have a simple UI for rollbacks

I was really hoping this would come with rollback support for deployments. That, to me, would be the big advantage of having gcp manage the tfstate. It doesn’t look like that’s currently supported, but maybe that’s coming in the future.

You can include a locked_at field and have your update query be for not_started rows and started rows where locked_at is older than the job timeout

That's an interesting dataset and it aligns with my gut reaction: TDD (and testing in general) are ideal for bug fixes and code refactoring, which would be less useful when the software is going to be sold at a specific point in time (and therefore frozen or mostly frozen).

I've been considering building a pwa and using a webview as a pseudo native app I know iOS support isn't great but it seems to be improving and iOS push notifications could be built separately in the meantime. How's anyone tried this approach?

Type guards also allow you to use Array.prototype.filter to modify the type of an array ie

  const maybePets: Array<Pet | undefined> = [...]
  const pets: Array<Pet> = maybePets.filter((v: Pet | undefined): v is Pet => v != undefined)

Will compile without errors.

Ah that's fair about flaw #7

I wonder if it would makes sense to enforce hooks being called through a top level React function. To make some of the ordering more explicit

  function MyReactComponent() {
    const [
      [width, setWidth],
      [name, setName],
    ] = React.use(
      [useWidth],
      [useName, 'alice'],
    );
    return <div>{width} {name}</div>
  }

admittedly, this is much less clean looking than the current proposal, but, in my mind at least, it makes it a bit more clear that you have to pass the functions in with a specific order at the top of the component.

This is a really cool implementation! I'm wondering if it wouldn't be possible to handle optimistic updates by submitting a request to the server and then submitting an optimistic response from the client to itself. Then, when the server comes back, you hook into the already present optimistic response and just confirm or deny it based on the response from the server. That way you keep as little state on the client as possible.

Thanks so much for letting us know we will take a look first chance we get.

Currently we have been focusing on a purely client side implementation, that being said our features are largely built to extend React and Flux and that should put us in a strong position to work with Isomorphic apps down the line.

Yeah I apologize for that we are still working on a mobile friendly version of the site.