There seems to be a strong strain of Lisp exceptionalism underlying a lot of 
the responses in this thread.  I don't think its profitable to assume that 
ClojureScript is a superior language, therefore React and Relay must be brought 
closer to ClojureScript, therefore we must fork them to make them that way.  I 
think that's the surest way to marginalize ClojureScript.

There are some very interesting architectural points made by Relay's 
architecture which I don't think are anywhere near "solved" in the current 
ClojureScript ecosystem.

* GraphQL is close to Datomic's new Pull sublanguage, but GraphQL has been 
designed so that the backend code can easily transform its queries into calls 
to a variety of datastores.  I think it would be a great boon to the Clojure 
community to have a unified library that understood something like 
GraphQL/Datomic Pull and was easy to write adaptors for other data stores as 
well.  Implicit in this would be a way to manage access control for all the 
levels of data.

* Placing the queries inside the component itself at first seems complected, 
but I currently live the "tab" example where I want new fields on the front 
end, so I write some code to display them, then open a different file to fetch 
them from the server, then open a different file to provide them on the server. 
 Ugh.

* Although they didn't show any code, handling a mutation by sending the new 
data along with a "refresher" query is about the best way I've yet come up with 
to deal with mutated data.  Think about it: let's say you insert a row at index 
2,000 in a large table view.  The server can probably calculate that the entire 
set of rows has changed, but how is it to know which ones you're currently 
showing to the user?  You could try to manage subscriptions for views on your 
data, but that requires syncing more state, or you could just punt and have the 
frontend explicitly calculate what it expects to change and needs to know about 
and specifically ask for that.

Anyway, that's my $0.02 from watching the presentation.

Brendan Younger

On Sunday, February 1, 2015 at 10:17:58 AM UTC-5, David Nolen wrote:
> There is no intention as far as I could tell to add Relay to React as 
> anything other than an optional thing, same as JSX.
> 
> 
> Forking React or starting from scratch has less and less value each passing 
> day - React Native is a good example of the benefits of sticking with a solid 
> platform.
> 
> 
> 
> David
> 
> 
> On Sun, Feb 1, 2015 at 10:14 AM, Marc Fawzi <[email protected]> wrote:
> 
> Not that the idea behind Relay does not make sense. It does, but there is at 
> least one class of scenarios where it doesn't, or does not make *complete* 
> sense. 
> 
> 
> Just saying that it if the React team decides to add Relay into React as 
> opposed to having it as an optional part of the "framework" then it might be 
> worth looking into forking React to keep things simple.
> 
> 
> And of course I could be very wrong.
> 
> 
> 
> 
> On Sun, Feb 1, 2015 at 7:10 AM, Marc Fawzi <[email protected]> wrote:
> 
> If you fork React today before Relays are added, wouldn't you get the 
> benefits that React has to offer up till this point?  
> 
> 
> Even Node got forked, but for completely different reasons. 
> 
> 
> 
> 
> On Sun, Feb 1, 2015 at 6:54 AM, Kyle Cordes <[email protected]> wrote:
> On Sunday, February 1, 2015 at 8:50 AM, Marc Fawzi wrote:
> 
> > Yeah I was going to ask at which point will projects like Om and Reagent 
> > decide to fork React...
> 
> >
> 
> 
> 
> I believe there is already a similar project that takes this approach. But it 
> has a significant challenge, it means not reusing the extensive work of React 
> to work correctly across the long history of semi-broken browsers. 
> Understanding and implementing dumb manipulation correctly across every edge 
> case is not the most fun work.
> 
> 
> 
> 
> 
> --
> 
> Kyle Cordes
> 
> http://kylecordes.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> 
> ---
> 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> 
> To post to this group, send email to [email protected].
> 
> Visit this group at http://groups.google.com/group/clojurescript.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> 
> --- 
> 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> 
> To post to this group, send email to [email protected].
> 
> Visit this group at http://groups.google.com/group/clojurescript.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.

Reply via email to