I mentioned "reactive programming" because React is typically used in conjunction with reactive programming. Mentioning something related to something else is pretty standard communication.
To elaborate on why I made my initial comment...
Reactive programming is a paradigm, it has advantages (and disadvantages). Paradigms are higher level than implementations (libraries), or even a programming languages. When people start a new project they come up with requirements; continuous integration, easily testable etc. These requirements are mostly satisfied by a paradigm, not a implementation, nor even a programming language.
If you've decided you like React, you probably like it for various reasons, most of which are probably because you're following the reactive programming paradigm - and perhaps because you like JavaScript. Nonetheless, when you start a new project (e.g. you've decided you want a native Mac app) it's your job as a competent software developer to determine the best fit for the project. This means you should really do your best to make a well rounded assessment of the situation - that means being educated about the subject matter. My comment merely agreed with the parent comment's description of the disadvantages of a (near) pure JS solution, and proposed ReactiveCocoa as an alternative that provides many of the advantages and familiarities of React, minus the disadvantages the parent post pointed out. Of course, you can't use JS to write your app - that may well be deemed by your team as a sufficient enough disadvantage to avoid ReactiveCocoa as a solution.
React has very little to do with reactive programming.
It definitely has similarities, but in React you do not map the dataflow in the same way you would in reactive programming. Only the flow of data through components could be considered reactive.
The real dataflow in reactive programming which could be considered the 'state', is not managed by React at all. You could use Redux for that, but having a datastore with reducers which modify state, and actions which trigger reducers is not something I would consider reactive.
Funny enough we are moving to a flux-style model for our view layer and using RAC signals for async stuff. The syncing and database logic is in a separate library that the main app treats as its official "API". That makes most of the interactions akin to Async Action Creators.
EDIT:
I mentioned "reactive programming" because React is typically used in conjunction with reactive programming. Mentioning something related to something else is pretty standard communication.
To elaborate on why I made my initial comment...
Reactive programming is a paradigm, it has advantages (and disadvantages). Paradigms are higher level than implementations (libraries), or even a programming languages. When people start a new project they come up with requirements; continuous integration, easily testable etc. These requirements are mostly satisfied by a paradigm, not a implementation, nor even a programming language.
If you've decided you like React, you probably like it for various reasons, most of which are probably because you're following the reactive programming paradigm - and perhaps because you like JavaScript. Nonetheless, when you start a new project (e.g. you've decided you want a native Mac app) it's your job as a competent software developer to determine the best fit for the project. This means you should really do your best to make a well rounded assessment of the situation - that means being educated about the subject matter. My comment merely agreed with the parent comment's description of the disadvantages of a (near) pure JS solution, and proposed ReactiveCocoa as an alternative that provides many of the advantages and familiarities of React, minus the disadvantages the parent post pointed out. Of course, you can't use JS to write your app - that may well be deemed by your team as a sufficient enough disadvantage to avoid ReactiveCocoa as a solution.