You can't convince functional programmers to use classes and old programmer to use hooks, everyone should use what they want!
I couldn't agree more. That was the main concept under the "Developer Cognition" section. And that's definitely part of my inspiration to write an article like this. I don't like any environment (which is all-too-common), where they have made some universal dictate like Thou Shalt Not Use Classes or Thou Shalt Not Use Hooks. Unfortunately, devs often get polarized on such issues.
I only ask myself how you deal with UI Libs like Material or Graphql Clients like Apollo who are going in hooks only direction, and likely all libs will go that way, do you still write Class Components then?
Yeah... I kinda referenced this in the "Legacy Compatibility" section. I haven't (yet) had any real problems with Material UI (and I use it all the time). I think this is because Material UI gives you a bunch of self-encapsulated components and then allows you to drop them into your own components - whether those components are functional- or class-based. When it's done like that, the functional/Hooks components really play quite nicely with classes.
It's kinda like TypeScript. I'm not using TypeScript in my dev. But many of the packages that I use are written in TypeScript. And for the most part... I don't care. Because all of their behind-the-scenes TypeScript doesn't affect how I use the package in the middle of my components.
I have, however, run into the exact problem you reference with GraphQL. In the latest/greatest Apollo library, they want you to reference the Hooks directly as a means to use the package. In those cases, you either convert your classes to functions (yech...) or you don't use the library at all. (Or you write some horrific, bloated wrapper function that allows you to leverage the Hooks from inside a class - also... yech.) I'll freely admit that this annoys the crap outta me.
I actually ended up scrapping Apollo altogether. But not exactly because of the "Hooks problem" (you can get versions of Apollo that play along just fine with classes). My "beef" with Apollo (and other GraphQL libraries I tried), is that they want you to hand control over the API calls to the render cycle - which I find to be completely untenable.
I wrote a post that references this broader issue here:
I ended up dropping all GraphQL libraries and I just wrote/formatted the GraphQL queries manually in my API components. Afterall, GraphQL is nothing more than a specific way of formatting a query (i.e., a string). And I realized that I didn't really need an additional library for that.
Would it not be easier for you to stop using React and maybe look in some new things like Blazor?
Yes and no. Sometimes I write some... "cantankerous"-sounding shit. But it doesn't mean that I've soured on React as a whole. In fact - I still love it. I just get frustrated sometimes by some of the forces that are driving it in suboptimal directions.
And I'm not a "Hooks hater". In fact, I've kinda switched most of my new dev to Hooks. Yes, they have problems. But they also have some really strong benefits. So it's a give-and-take.
Also, when it comes to new libraries/frameworks/paradigms/etc., like most devs, I'm always looking at other alternatives with genuine curiosity. But I also really enjoy the process of getting a paycheck.
It's one thing to say, "Oh, man! I just found this brand new library/framework/paradigm/etc., and it's friggin awesome!!" It's an entirely different thing to take that back to your team (or your company) and say, "Here's why I think we should totally abandon all that React stuff we've been doing and adopt this Hot New Thing."
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I couldn't agree more. That was the main concept under the "Developer Cognition" section. And that's definitely part of my inspiration to write an article like this. I don't like any environment (which is all-too-common), where they have made some universal dictate like Thou Shalt Not Use Classes or Thou Shalt Not Use Hooks. Unfortunately, devs often get polarized on such issues.
Yeah... I kinda referenced this in the "Legacy Compatibility" section. I haven't (yet) had any real problems with Material UI (and I use it all the time). I think this is because Material UI gives you a bunch of self-encapsulated components and then allows you to drop them into your own components - whether those components are functional- or class-based. When it's done like that, the functional/Hooks components really play quite nicely with classes.
It's kinda like TypeScript. I'm not using TypeScript in my dev. But many of the packages that I use are written in TypeScript. And for the most part... I don't care. Because all of their behind-the-scenes TypeScript doesn't affect how I use the package in the middle of my components.
I have, however, run into the exact problem you reference with GraphQL. In the latest/greatest Apollo library, they want you to reference the Hooks directly as a means to use the package. In those cases, you either convert your classes to functions (yech...) or you don't use the library at all. (Or you write some horrific, bloated wrapper function that allows you to leverage the Hooks from inside a class - also... yech.) I'll freely admit that this annoys the crap outta me.
I actually ended up scrapping Apollo altogether. But not exactly because of the "Hooks problem" (you can get versions of Apollo that play along just fine with classes). My "beef" with Apollo (and other GraphQL libraries I tried), is that they want you to hand control over the API calls to the render cycle - which I find to be completely untenable.
I wrote a post that references this broader issue here:
dev.to/bytebodger/react-s-odd-obse...
I ended up dropping all GraphQL libraries and I just wrote/formatted the GraphQL queries manually in my API components. Afterall, GraphQL is nothing more than a specific way of formatting a query (i.e., a string). And I realized that I didn't really need an additional library for that.
Yes and no. Sometimes I write some... "cantankerous"-sounding shit. But it doesn't mean that I've soured on React as a whole. In fact - I still love it. I just get frustrated sometimes by some of the forces that are driving it in suboptimal directions.
And I'm not a "Hooks hater". In fact, I've kinda switched most of my new dev to Hooks. Yes, they have problems. But they also have some really strong benefits. So it's a give-and-take.
Also, when it comes to new libraries/frameworks/paradigms/etc., like most devs, I'm always looking at other alternatives with genuine curiosity. But I also really enjoy the process of getting a paycheck.
It's one thing to say, "Oh, man! I just found this brand new library/framework/paradigm/etc., and it's friggin awesome!!" It's an entirely different thing to take that back to your team (or your company) and say, "Here's why I think we should totally abandon all that React stuff we've been doing and adopt this Hot New Thing."