Completely agree. Class components are so beautifully simple. Hooks have infuriating edge cases and are so bizarre they need ESLint plugins to remind people how they work.
312 karma · joined April 24, 2016
Airborne training is "safe" in the sense that they thoroughly teach you all the steps and do lots of ground training before getting in a plane. But by no means does that mean your body won't get wrecked by doing jumps.
The parachutes are designed for combat: their goal isn't a soft landing, it's to get you out of the sky as fast as possible.
I was stationed in Alaska. Wintertime jumps were a toss-up in terms of landing in a big pile of snow — or solid ice.
/s
All of that is true about my Army experience lol. If I could go back and do it again, I'd definitely choose Air Force. I agree that the military can be a positive experience and it's a good idea for some people, but the caveat with my endorsement is that you gotta carefully choose the branch and the job.
I almost chose linguistics, but for some silly reason chose mechanic and paratrooper, and wouldn't you know it I ended up with injuries causing me to walk with a cane in my 20s.
I've built some really complex frontends with React. But now here I was, struggling with setInterval, ha.
Edit: after writing this I went and read the article. Same scenario I was bitching about lol
Class components are dead simple. A class, a setState method, this.props, this.state, and some lifecycle methods. SO easy for anyone to understand.
Function components with hooks are not. A whole new (and unnecessary) paradigm; some mysterious hooks engine that needed new ESLint rules to be created just so people can keep the weird, delicate balance in place; hooks having their own timing problems, requiring usage of useRef which the React team tries to get people to avoid; etc.
Frontend codebases used to have several layers, with React just being one of the thin ones. Now, nearly the entire frontend codebase is inside React world. I'm not a fan of this direction.
Class components are so stupidly simple to read and write. I appreciate the work put into function components, but to me they make things unnecessarily complex. Just the fact that they took callbacks and other functions from methods – where things are separate, clean, standard – to nested functions – where things are not separate (some local variables, some closure variables), not clean (no possible way to unit test a nested function in isolation), and not standard (object methods are a language feature, use them!) – seems like a huge step backward.
Guilty as charged. I needed to hear that :)
My complaints about hooks are that with hooks we lose useful tools in our react toolkit: class methods, separate componentDidMount/componentDidUpdate lifecycle events, shouldComponentUpdate, PureComponent, etc.
And my biggest complaint is that we're losing simplicity. React spread like wildfire when it first came out because it was so beautifully simple: a class, with something called `props`, and this.state and this.setState(). That's it. You can build SO MUCH with just that.
To me, with hooks, React's simplicity is being replaced by cloudiness. There's so much "magic" now. The order of hooks in the code is the most important thing for a hook component to work right. New linter rules had to be built to remind people where hooks need to be written.
I do appreciate the work that's been put into hooks. And like any other open source project, I'm incredibly grateful to the authors and maintainers. I guess I just wonder if anyone shares the same sentiments as mine, because it seems like the only thing I read about this topic is that classes suck, class components are full of pitfalls, etc.
- The `Query.skip` prop. I'd like to know all of the expected behavior for when this prop is used. For example, I've noticed that when skip is true then the render prop function's `data` object is always undefined, even though the data is there! Also when skip is true and you manually trigger a refetch elsewhere (for example when running a mutation with `refetchQueries` specified), the `onCompleted` prop doesn't get called, even though the query was in fact refetched and completed.
Those are just recent things I've noticed. Also for the record I don't mean to sound like I'm throwing shade. I appreciate all open source work and the Apollo projects are massive open source contributions, so thank you :)
First off, thank you for what you do. Microsoft is kicking ass these days and I don't want to sound like I'm unappreciative or unimpressed with what you guys are doing.
A quick example could be user authentication:
https://docs.djangoproject.com/en/2.2/topics/auth/default/ https://docs.microsoft.com/en-us/aspnet/core/security/author...
The first thing I see when scrolling down those pages is that the Django page is ~90% descriptive text and ~10% code. The ASP.NET page is the opposite: ~10% descriptive text and ~90% code.
Obviously that's not the best metric but I need to get off HN soon so that's the best I have for now :)
In any case, this could support my earlier claim: Django docs give not just the "what" – they also provide the "why", along with super useful background/supporting information, and even alternative approaches (e.g. in the "Limiting access to logged-in users" section there are at least five avenues you can choose from to meet your needs).
That was the quickest example I could find. Sorry it's not more substantive. I'll post again later if I find something that could be more helpful.
And again, I really appreciate what you guys are doing and don't mean to sound like I'm sending any negativity in your direction <3
Been using VS and VSCode for a long time.
Don't care that the docs are open source.
My issue is that I guess I have high expectations for the official docs of a platform/framework/library/whatever. You shouldn't have to buy a book or read a random blog to find critical information on core functionality. The official docs should provide that, and Django is a great example. It includes how to do things, why things are the way they are, how to customize workflows, best practices, pitfalls, and on top of all that the source code is super easy to read and understand.
The pages at docs.microsoft.com are mostly just basic walkthroughs that leave me with a lot of questions. And the .NET Core source code is not nearly as readable.
It's getting better though. And I don't mean to take jabs at Microsoft because I truly do appreciate how much they've done in open source over the last few years, especially with VSCode.
I want to love .NET Core development because I love Microsoft’s open source effort, but the support (or lack thereof) from the documentation is quite the hindrance.
To go from mature backend frameworks with autogenerated REST APIs to manually writing a lot of boilerplate code just to get a _basic_ GraphQL API running is frustrating. Part of the blame goes to the marketing of GraphQL. For example, the tagline on graphql.org is "Describe your data | Ask for what you want | Get predictable results". That's all well and good, but it leaves out the large majority of the work you have to do. This describes the schema, the query, and the result; but what about all the resolver code you have to write? That's the painful part of the whole process, especially when you get to the point of writing field-level resolvers and integrating child objects (DataLoader, etc.).
And then on the frontend, Apollo is preaching for us to write client-side queries AND client-side resolvers to fetch data that's _already in the cache_. All of this just to read, for example, a single primitive value? This is just too much.
I'm just getting started on this path, and I'm really starting to see that like you said, excellent customer service--not beautiful code or elegantly applied computer science principles, etc.--is the most important thing.
Now I just need to figure out how to establish that network and reputation. Thanks again!