Thanks, that puts me onto a helpful path. I’m relatively new to this world of React and Node and still getting a feel for the various components involved.
After a brief perusal of Redux, I have a better sense of how it might contribute to the solution, though I think it still would involve reproducing business logic in Redux reducers (based on a mere 10 minutes’ worth of skimming the Redux docs). That may be fine, though.
Here’s a little more detail about my specific project to give you a feel for the problem I’m trying to solve:
I currently have a WordPress based web site. I’m pretty happy with the functionality I get from the ecosystem of plugins that I’ve integrated together, but some aspects of the resulting user interface need tuning and I think React can help.
It’s a learning site that involves Sensei (a learning management system), bbPress (for forum-style discussions and topic threads that are bound to Sensei lessons), BuddyPress (for social networking features, and mostly to provide users with a single news feed of activity updates from the various courses and discussions they may be participating in), and BadgeOS (to award achievements to participants for things like engaging in the discussion threads as partial completion of course requirements).
Each of these plugins is a pretty significant chunk of software with a lot of logic that operates on its own data. And then I have created some additional meta data here and there that my own custom integration plugins use to glue these different pieces together.
For example, I wrote a small plugin that lets me associate both a bbPress topic and a BadgeOS achievement to a Sensei Lesson. So when a learner is looking at a Sensei lesson page, and maybe watching a video for that lesson, there’s a discussion thread embedded there below. Earning the BadgeOS achievement is a prerequisite for completing the lesson—that achievement is earned by participating in the discussion.
A challenge: I want users to be able to engage significantly in the lesson’s discussion while remaining on that Sensei lesson page, but bbPress by default would redirect the user away from that page if he were to add a reply to the discussion and click submit.
My initial solution to that problem simply involves using Ajax to submit replies on that embedded topic. Works well enough for now. In the future, though, I have other ideas to allow learners to engage in more ways—without leaving the context of that lesson page: editing their replies, filtering replies, posting replies with scoped visibility (e.g. for my team’s eyes only), replying to replies (nesting one level).
So I started exploring how I might accomplish that with React, which led me to your article series.
To focus all of this down to just that one use case, then, this React client needs to be able to show the current user a single topic (if the user has access), associated metadata (like # of voices in the conversation), and any replies that the user has access to (for now, if a user can access the topic, he can access all replies associated with it). So yes, the client does know what data it needs (the GraphQL idea about which I raised my initial question about); but also, the client relies on the server—specifically the logic found in bbPress to return only those items that the user has access to. If the client were to circumvent the bbPress code layer and go straight to the MySQL database (even if via GraphQL), it would somehow have to reproduce all of the visibility logic that lives in the bbPress code in order to get the correct answer.
So far, I’ve done a very basic proof-of-concept without GraphQL where all of the data is supplied via the WP Rest API. Because bbPress models both topics and replies as types of posts, I was able to use the built-in WP_REST_Posts_Controller for most of the heavy lifting and simply extended it with subclasses for topics and replies, adding very minimal code for things like check_read_permission() or tweaking the query arguments.
By doing that, I’ve admittedly already added some logic that reproduces what is found in bbPress core—such as how topics are associated with replies. If the same sort of logic were expressed in a Redux reducer instead, it would be no worse, I suppose. But my goal would be to encode logic at this layer—whether implemented in REST endpoints, or Redux reducers, or whatever—that’s no deeper than what would be found at the bbPress template code layer. I don’t want to circumvent the bbPress core code layer, to respect its encapsulation and to avoid having my app break if bbPress core should change something about the underlying model down the road.
Do you have any suggestions?