How to Handle Inconsistent Coding Styles Among Co-Workers

Code Transfer Advantage

Following patterns provided by a library, React in your case, means that the product you deliver will be easily picked up and maintained by other developers who are also familiar with React.

Potential Backward Compatibility Issues

Some libraries would have a new major version out, and backward compatibility might be compromised if your patterns are significantly different, thus slowing/halting your future upgrade. I am not sure how React would deal with new releases, but I have seen this happen before.

New Members on The Team Start Being Productive Quicker

If you follow what is provided by the author, you are more likely hiring talented developers using your framework and start them off quicker with your system rather than teaching new patterns.

Potential Undiscovered Issues

There might be issues in the future that you haven't discovered yet with your approach, that are solved by the author's approach.

That being said, innovation is always a risk, if you strongly feel that your approach is better and it works for your team, go for it!

1. Have a coding standard. If the shop you're going to work for already has one in use, that's the one you follow. Avoid coding standards that are dozens of pages long; it's not that complicated. Instead, look at code you like on Github, and follow that style. Find the well-established idioms for your particular programming language (camelCase, etc.), and use them.
2. Let the IDE and code style tools do most of the work for you. For example, Visual Studio already has most of the important rules in place. Don't like how a piece of code is formatted? Ask Visual Studio to reformat it for you. Problem solved.
3. Hire software developers that know what they are doing. They'll write good code without having to slavishly follow a style guide.
4. Have code reviews. Seek consensus based on function and readability. Don't like the consensus? One person is the tie-breaker; their decision stands.
5. Don't strive for perfection; you'll never get it (for many, many reasons that are outside the scope of this question). Instead, strive for improvement.
6. Try not to waste a lot of time and money on things that don't matter. In particular, don't rewrite code that already works and is already well-tested, just to satisfy your own sensibilities about what that code should look like.
7. Learn how to write functions and methods that do one thing and do it well. If you do that, your naming should take care of itself (the name is a short verb phrase that describes what the function does).
8. If you're doing OO, learn how to write small classes that have one responsibility/point of modification. If you do that, your naming should take care of itself (the name is a short noun phrase that describes what the class is).
9. Learn how to write code that is easily testable. If you do that, the unit tests will take care of themselves.
10. Pick your battles. Does that small, obscure proclivity that one of the developers exhibits really matter? Avoid religions and dogma.
11. Finally, remember that the code is not yours. Don't be sentimental about it. You should "own" it and make changes as required (so, in that sense, it is yours), but it's there to serve a purpose. Being overly attached to the code only gets in the way of that by preventing objective analysis of the pros and cons of large-scale changes or decisions about the structure of the code and making you object to compromise.