> 1. There is no need to fork React now or in the future because React is a > library specified for one purpose, not a framework that can get bloated over > time.
Now - I don't see any benefit that would justify that. Future - Who knows? I never claimed to have a crystal ball. My 2 cents is that the React team appears to share many common values with the Clojurescript community, among those a preference for small focused libraries that do one thing well. So it's logical to assume that won't change any time soon, and if it does then we address it then. > 2. Relay is both interesting and useful The ideas are interesting, too early to say how useful. > 3. Scenarios where Relay would be counter productive? I mentioned one, and if > it's not correct that Relay would complicate that scenario then I'd > appreciate an explanation, to better understand how Relay works in that > scenario. I don't think anyone is claiming that Relay is the right approach in every use case (or even any use case - like I said, it's too soon to tell). For the example you gave, it doesn't seem to be appropriate. But this goes towards my point - not focusing on this monolithic thing called "Relay" and instead focus on the underlying ideas, such as: - components that declare their data requirements - aggregating component data requirements in order to optimize what data is queried for - providing a service endpoint that allows these types of queries - using the knowledge of component data requirements to optimize re-rendering when new data is received from the server That's just off the top of my head. Some, all, or none of those ideas may apply to your particular app. Even if the entire Relay approach is a perfect fit, there are other choices to be made, like using GraphQL or Datalog for queries. But the bigger question is "why?". Their rationale is keeping the data specification co-located with the components, rather than spread out across multiple locations. Great idea! Then the next question is - what are the tradeoffs? Do the benefits outweigh the increased complexity? Every app and every team will have different answers to these questions - that's why small, composible libraries and good abstractions are more useful than "one side fits all" frameworks. -- 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.
