[voxmatt]

Exciting to see! I've been waiting on this since we decided to use Relay for our application about 6 months ago. Relay is amazing but quite an investment (especially mutations).

I'm a bit worried, however, that Relay Modern has focused a bit too much on the internal needs of a massive application like Facebook at the expense of fleshing out some of the rough spots of working with Relay.

Simpler, more explicit mutations is a wonderful improvement, as is more granular control over the cache, but there's no mention of subscriptions or client-side state control (using Redux on top of Relay is... doable, but not as elegant as one might hope for).

That all said, this is an impressive release and congratulations to the team. We're committed to Relay and hope this release grows the community.

[voxmatt]

Follow-up (didn't see the updated docs). Looks like there is some support for client-side state through "Client Schema Extensions" — excited to play with this.

I do also hope that this iteration brings with it better docs — that's the one area where I've looked over at Apollo longingly. On many occasions I've discovered unknown patterns in stack overflow answers that aren't documented anywhere (credit where it's due: the answers are often by members of the Relay team).

And one final tangent: the day when Facebook gives up on flow and adopts Typescript will be a glorious, glorious day.

More here: https://facebook.github.io/relay/docs/new-in-relay-modern.ht...

[cies]

> the day when Facebook gives up on flow and adopts Typescript will be a glorious, glorious day.

I foresee FB to skip TypeScript and go straight with ReasonML[0], as 25%[1] of the messenger code base supposedly is already converted to Reason.

And I think that is even more glorious development then FB going with TypeScript. :)

[0]: An easier to approach (for programmers coming from mainstream languages; like JS/C++/Java/C#) syntax on top of the OCaml language, and some new tooling. The tools integrate specifically well with BuckleScript (by JaneStreet) which provides the OCaml compiler with a JAvaScript compile target.

[1]: https://news.ycombinator.com/item?id=13980062

https://facebook.github.io/reason

https://github.com/vramana/awesome-reasonml (some links to example code in the last section)

[trishume]

BuckleScript is by Bloomberg, specifically https://github.com/bobzhang, not Jane Street. The developer of js_of_ocaml, the other JS to OCaml compiler, works at Jane Street though.

[cies]

Oops, sorry. Cannot edit anymore. So please everyone read this!

[staticassertion]

Last time I looked at reason it was totally new and there was no tooling etc. I got little support from the gitter or whatever it was.

Have things changed? It really interested me at the time.

[sgrove]

Worth stopping by the discord [0], it's grown quite a bit and so has the (editor/build/etc.) tooling. There's no Apollo/Relay story yet (that's the biggest missing piece for me on the client side), but everything else is pretty decent!

[0] - https://discordapp.com/invite/reasonml

[twoquestions]

It was a bit tough to get tooling set up and it doesn't work on Windows, but on Mac (and Linux I assume) it's amazing. Better Intellisense support in VSCode than Typescript!

It is very new though, and I haven't got a complete grip of JS FFI with Reason.

[ivan7237d]

Hey a quick question — which Flow extension are you using? There's the official one called "Flow Language Support" and another one called vscode-flow-ide.

UPD: sorry, I just realized you were talking about Reason, never mind.

[rattray]

> the day when Facebook gives up on flow and adopts Typescript will be a glorious, glorious day.

Why?

[voxmatt]

Because I use Typescript! Joking aside though (although, let's be honest, there is some straight-up selfishness: I use TS and if Facebook did, my life would be easier), I think adding types to Javascript is a huge win no matter how its accomplished and it just so happens that TS seems to be gaining more community support than Flow. Flow's support is almost exclusively from the React community because of Facebook. If Facebook would switch to TS, the whole community could coalesce around one standard. That would have huge benefits.

[wincent]

> I do also hope that this iteration brings with it better docs

The docs are very minimal this point with some definite gaps (we had a bit of a scramble to get them written in time for F8), but the point is well-taken: Relay docs need to get better. Luckily, the design of Relay Modern is simpler and easier to understand and explain; there is less (no?) magic involved, so we should be able to get the docs to a much better place now.

[linkmotif]

Now that mutations are so much simpler, would be great if there was some discussion of what you get from connections. Previously this was only well explained in blog posts by Huey Petersen.

Thank you!

[josephsavona]

Thanks for the feedback!

> but there's no mention of subscriptions or client-side state control

The blog post didn't cover all the new features, but both of these use-cases are supported in Relay Modern - https://facebook.github.io/relay/docs/new-in-relay-modern.ht...

GraphQL Subscriptions are supported: applications must inject a network layer that provides support for connecting to the server and receiving subscription updates. Local state is supported via client-only extensions to the schema, combined with an imperative update API. More docs coming soon :-)

[aj0strow]

I read architecture.md in the runtime package and it looks perfect for binding websocket updates into components. I was really hoping for the following example:

* create a stand-alone relay store

* query and subscribe to changes, print to console

* imperatively push updated records into store

* see updated data in console

I assume this is possible, but maybe it's not? Or you need a graphql server or container component?

[djmashko2]

I'm excited to build an example with Relay Modern and the websocket subscriptions transport, should be really cool!

[voxmatt]

Awesome!

[vning93]

Very excited as well for the release of Relay Modern! I think overall a huge boon for the Relay developer experience.

I'm with you here on the static queries. We've used Relay a couple of times as well for various smaller applications here and there, but honestly felt the "magic" was too strong. I'm looking forward to building my future apps and try out Relay Modern.

In addition, I want to be able to encourage more applications that build on our GraphQL platform called Scaphold.io (https://scaphold.io) to try out Relay Modern as well since our API is built to the Relay spec. With that in mind, I'm hoping that the spec will be less restrictive in the future, so there's a smaller learning curve for folks trying it out.

As for the concern with focusing on the internal needs of Facebook, I think the experience that they have working with one of the largest distributed systems in the world helps (rather than limits) their vision on what Relay can be. I trust that this is the case, though it would be really great to see some of the tooling for native support (i.e. iOS, Android, etc). I'm sure they've got that somewhere waiting to be released as I can imagine they have plenty of mobile teams at Facebook who aren't using React Native yet.