31–40 of 133 posts
Any example anywhere of using context for current authenticated user?
I have very mixed feelings about the new context api. On one hand, you're taking a foot-gun away, which I approve of having worked on code bases that abused it. On the other hand, it's very clunky, and I think people who abused the old context will just start making components larger, and wrapping them in a single context, rather than doing the right thing with many small components individually wrapped. Personally I…
React API reminds of Microsoft COM for JavaScript. It was called Component Object Model. It was hell to deal with when lasted.
I've been thinking about different situations in which Redux could be replaced with the new Context. Id sure appreciate having to write less boilerplate. The biggest concern I always get stuck on is where I'll put all my app's business logic, which I'm so used to putting in async redux-observable or redux-thunk actions. Does anyone have anything ideas on how to make an elegant business-logic-full Provider component?
As for the "boilerplate" topic: you are encouraged to use as little or as much abstraction on top of Redux as you want, whether it be small utility functions or entire other frameworks that wrap Redux. We've got a "Reducing Boilerplate" page in the docs [1], and I've got a section of my React/Redux links list for articles on that topic [2].
I'd be happy to suggest possible solutions for whatever problems you're concerned about.
[0] http://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/
[1] https://redux.js.org/recipes/reducing-boilerplate
[2] https://github.com/markerikson/react-redux-links/blob/master...
In the unlikely scenario of Facebook's demise, how do you think the maintenance of React would transpire? Do you think some other tech company would snatch up the design leads, and pick up the torch? Would it go into its own independent organization?
React API reminds of Microsoft COM for JavaScript. It was called Component Object Model. It was hell to deal with when lasted.
The downvotes are unfortunate, since this is a reasonable sentiment, here's an article I read a while ago that presented this point in a more nuanced fashion: https://bitquabit.com/post/the-more-things-change/
(And yes, that's a very good post.)
In the unlikely scenario of Facebook's demise, how do you think the maintenance of React would transpire? Do you think some other tech company would snatch up the design leads, and pick up the torch? Would it go into its own independent organization?
There is no demise coming for Facebook. They'll clean up, grandma, aunty and the school mothers will continue posting and they never even knew there was an issue. People will soon forget.
https://www.theguardian.com/technology/2007/feb/08/business....
It seems like react gets re-written and APIs undergoes drastic changes every few months. I'm not complaining about churn (I don't write react), but rather that maybe React isn't the right tool to be hyping up, or pointing newcomers to JS at to look into/use.
I don't remember any other supposedly simple library having had this many major rewrites/api changes. I don't think I've ever seen something like this in KnockoutJS or even Angular1 for a long time (even though the way you had to handle $scope and apply/digest cycles was terrible). Relative newcomers like Mithril and Vue seem to get this stuff right without requiring as much breaking changes. Maybe they owe their simplified structures to some of the new thought to what React inspired, but it seems like they're actually simple (Vue's documentation is amazing, concise, and you can actually render Vue in the browser to get started quickly).
Maybe it's time to rethink whether React is a good tool. There's no way I would recommend React to anyone (beginner or intermediate) over something like Vue these days.
For example, I don't know what HOC (and am thoroughly uninterested, it sounds like the same kind of thing you only need to know when you're chest-deep in React land) is but it sounds like a hack necessary because of a bad design decision.
[EDIT] - Took a few seconds to look up HOCs (Higher Order Components) and they're a bad example of what I think is incidental complexity inside React but I think my point still stands. To clarify, here's my thesis:
React is complex (both internally, evidenced by multiple rewrites, and with the tooling it forces you to use, evidenced by needing to download a zip file to start, or touch webpack), but masquerades as a simple library.
disclaimer: I don't like react. Outside of dom node diffing and a focus on components I don't think it brings much to the table considering the considerable complexity it brings. It seems like react gets re-written and APIs undergoes drastic changes every few months. I'm not complaining about churn (I don't write react), but rather that maybe React isn't the right tool to be hyping up, or pointing newcomers to JS at…
I think it's a great library and has only really gotten simpler and better. But, to each their own.