People are all driven by something, and it is not being gritty for the sake of gritting. Figure out what it is and you can hack yourself into whatever you want just by pushing this "get up and get it done" motivational button. Find reasons why whatever goal fits with your deeper purpose and motivation will be by definition.
Both at the beginning and in the end the answer is always simple: hope. Not all people. There are good ones, even in technology. There are coworkers with whom your shared emotional experience was authentic. There will be more.
I initially had a few, but after making sure they weren't just learning curve exasperations in disguise, I realized they all boil down to that they should've just started out with this and never had any class components.
I often see developers mix up classes and functional components with hooks in abominable ways, and every pitfall to hooks I can find just boils down to improperly brackish OO class model polluted thinking.
All of this reads akin to someone criticizing an apple for not being an orange. Every point is an intentional design decision. Learning new things is necessary, leaving class syntax behind was a choice, and imposing limits on (controlling) application design is the point of libraries.
The team is pushing a functional declarative pipe method of building UI applications where things are built using a straight-line series of composed functional transformations. Personally, I think supporting this method with the hooks model of handling side effects is an improvement over everything else that exists in "roll your own" UI library land. I find these style libraries more enjoyable to build with, more expressive, and better suited to building things where you need finer grain control than template style libraries like Vue, which provide a stronger degree of predictability and ease of immediate use.
That's the thing -- it's a balance. Hooks add a nicely considered and balanced degree of order to the otherwise intentionally uncontrolled-so-you-can-do-the-controlling programming model of React. React identifies as the advanced lego set with the smaller more numerous blocks that you can build the cooler stuff with, and as such will always have a certain threshold of complexity.
You didn’t actually counter any of the authors’ points.
This wonderful functional declarative pipe method of building UI applications where things are built using a straight-line series of composed functional transformations can really suck in real world applications as he tries to demonstrate. Anyone building with hooks now can relate to hooks bringing disorder to the codebase.
Has your experience been different? How did you avoid the pitfalls mentioned?
1. It's not more stuff to learn, it's different stuff to learn, arguably less. Learning Components is not a prerequisite for learning Hooks. Or perhaps I missed the memo, as I've built an app using Hooks, and still haven't need to learn what 'componentWillMount' is supposed to do.
2. Don't mix Components and Hooks.
3. Agreed, change is hard. It's also the only way to avoid stagnation. In the long term, change wins. Or else we'd be programming in JS1995.
4. Insufficient example. What is the business case for a memoized hook returning hooks? Perhaps there is a simpler design, can't comment.
5. There is no global control flow. There is only per function component control flow, which proceeds from top to bottom. Possibly preempted by a hook/hookfn execution, if my early learning curve is to be believed. Which shouldn't matter if one is thinking in terms of 'pure functions returning jsx', as preempted functions do not return, thus have no observable effect.
Tip: Only change hook state from event handlers, never from render function code.
> In the long term, change wins. Or else we'd be programming in JS1995.
Change for the sake of change is not a sound argument.
The thing about hooks is they don't enable a single thing we couldn't already do with HOCs. They are also much harder to read, because stateful logic is now just sprinkled around your render method rather than being isolated to places you know to look for it. I won't be using hooks ever, as far as I'm concerned.
He/she gave a very valid critique of state being jammed into your render method, vs state being handled in a predictable pattern in Class components.
And lastly, let’s not minimize change-cost. In the real world, it’s a cost. We’re all willing to pay it if it’s necessary, or affordable, but not because someone showed up and said ‘change please’.
Well #2 isn't really a pitfall, for starters. I have a new feature that solved a problem I had but I can't use it in the code I wrote before I had it without refactoring? I don't think that critique really has anything to do with Hooks, just software development. It's also basically a rephrasing of #3.
> imposing limits on (controlling) application design is the point of libraries
That's the point of _frameworks_. It's very ironic to see this being said in defense of React, given that its original appeal was precisely the opposite stance (i.e. React was "only the v in mvc", in response to the notion that frameworks of the time were imposing).
Sounds like you know exactly what your problem is. Technical interviewing is just like normal problem solving, just you have to narrate your thoughts as if the interviewer's inside your head with you. Get some sample problems that match what you're seeing in your onsites, roleplay having an interviewer there with you, and practice them while recording yourself. Best is if you can have a real human. If you're passionate enough, it would be a great idea to organize some kind of group for people in similar positions.
Either you will learn the skill enough or you will find a position that fits your current skillset along the way. Being understood by other people is where the rubber meets the road for ideas having any impact and communicating your technical ideas is an important skill in general.
Aye, I hear you. I was giving it more thought over the last few days having written the above comment, and I realised that what happens in tech interviews is that I switch my mode of thinking.
Under normal circumstances, I sit and problem solve, thinking only of the issue at hand, branching out and following leads and so on.
Under interview circumstances, I instead try to anticipate what the person scrutinising me wants to see, and try to like, game an ungameable situation, which blocks my natural problem solving thinking.
I have noticed that when I'm in a position of subordination, I do worse creatively. This isn't to say I can't work as employee, but rather in specific situations, such as "person knows x and is just watching me try to do x", I enter this reactive thought mode.
Conversely, when I am in a superordinate position, I find myself much more creative than my baseline, thinking clearly and well.
Agreed. What I get out of that is that we can get more useful info out of perspectivism if we look beyond just the individualism-collectivism way of framing perspective and consider how the fact that some scientists favor holding interdisciplinary perspectives so that they basically have more ingredients for their guts to cook up new hypotheses with implies that there exists an area of study where you examine the relationship between holding one or many perspectives and the conclusions that follow, which could serve as a less subjectively constrained way of thinking about thinking.
I also agree that this is borderline self parody because it's much too thick with itself to be an enjoyably stimulating read, at least for anyone who isn't well versed in the vernacular already. It also has a ton of typos given the level of language it's trying to use.
> This turn has been facilitated by the lack of technical kwoledge
Happens to me all the time. Your conscious experience is the product of you processing a staggering amount of information from the world, and you're not aware of most of that processing. I would say give therapy a try.
What you'll have to do is basically just science on yourself -- make a hypothesis, test it, interpret your findings, and repeat until you know how you work. Therapy is more or less learning how to do that for all the soft emotional stuff in your head and learning how to manage your personal stress.
In my personal experience, generally yes given that you are able to carve your application logic into acceptably sized components. IMO what works best is not so much a hard single-file rule, but rather a looser single-location principle. If the component's logic is massive and necessitates many files, create a folder for that component and put them all in there. If a component is this large then it can also be a helpful signal that perhaps application logic could be factored differently so as to produce more easily understandable units. If there is enough discipline and alignment amongst the project developers, then the single-location thing lets you take advantage of making big logic easier to grok by allowing separation while keeping stuff that all belongs under a single umbrella grouped together.
It's a myth that it's not possible to maintain a holistic perspective that melds both the trenches and the command tent behind the lines. The best technical leaders I've worked with were the best because of precisely this: the ability to contextualize trench level decisions within command center level perspectives and vice versa.
