Apparently React is already moving from "Technology X will solve all problems" to "Technology X considered harmful" pattern.
React: Mixins Considered Harmful
111–120 of 205 posts
Re: React: Mixins Considered Harmful
#112For those of you complaining about "javascript complexity": I think one of the biggest misunderstandings about JS and a large portion of the community complaining about "churn rate", is that JS does not have a churn problem, it has an inexperienced developer problem. Which is not to say that is a bad thing, JS/web is the first language for MANY programmers now. When you get stuck on learning this framework vs that fr…
0.3 - 0.1 = 0.19999999999999998
Floating point error, present in every language that uses floats. This is in no way unique to JavaScript.
Re: React: Mixins Considered Harmful
#113I believe as time passes, we are moving away from the simplicity that made React win. Flux, Redux, higher order components generate too much complexity most of the time. React used to be simple, it still is, but the ecosystem and the mentality has gotten needlessly complex.
I think React is moving towards a simpler abstraction. There is nothing simpler than a function with the type Model -> View.
Re: React: Mixins Considered Harmful
#114Earlier quoted context omitted.
>I had an impression, that React community (not the authors) considers Redux as an best-practice. A part of React community, yes. Another part, no. Guess which part is vocal because they can write tutorials, examples, articles that generate clicks? ;-) I am as guilty of this as anyone of course, if not the most. Obviously React has some deficiencies addressed by Redux. So does Redux have deficiencies addressed by Rea…
I did. I started with React itself. Then I added Redux (first time, it was beacause of the project manager decision). I really like the state reducers. I find internal state clumsy, beacause you have three kinds of functions around the very same state object - get initial state, get state after some props changed and get state after some user action. For simple cases they are very similar to repeatedly write, but sti…
I never put everything in the one-big-store that rules them all either, but you don't really need to do that.
Alternatives:
- internal state (sometimes useful, especially for small things that doesn't matter for your underlying data - eg, "is this part of the tree unfolded"). Preferably, with very little logic linked to that state. Note that it can bite you if you use something like redux-undo on your store and your internal state refers to the data controlled by the store.
- temporary stores (create a store with a callback function in an event handler, and feed it a callback that invokes an action on your main store)
- smaller, specialized stores that get a projection of the data of you main store (this gets a bit awkward with async actions)
I'm also trying to avoid fully-controlled text inputs with textareas, I use wrappers with local state which send their content via onBlur().
Re: React: Mixins Considered Harmful
#115So uh, HOC's are basically monads. Right?
I think the intuition might be a little bit related but AFAIK monad is a very specific thing (can “lift” something and map functions over it, or at least that’s what I remember from a monad tutorial), and HOCs are different (they just wrap components). “Decorator” might be a closer pattern. I would say HOC is more like a regular higher order function... which is why it’s called this way. :P
I agree, a "higher order component" just isn't a monad. A HOC is just good old fashioned object composition. I think you are right to call it the decorator pattern. It annoys me how React ,and in general the entire javascript ecosystem, reinvents the wheel, then gives their invention another name.
Re: React: Mixins Considered Harmful
#116I believe as time passes, we are moving away from the simplicity that made React win. Flux, Redux, higher order components generate too much complexity most of the time. React used to be simple, it still is, but the ecosystem and the mentality has gotten needlessly complex.
I think React is moving towards a simpler abstraction. There is nothing simpler than a function with the type Model -> View.
Yup - trying out Elm makes you realize how much complexity is in the React + Redux stack that is not really needed...
Re: React: Mixins Considered Harmful
#117Earlier quoted context omitted.
What I think OP refers to, is how there are so many different choices to do anything in the React ecosystem. It's cool that people share their work. But so many choices just cause decision fatigue. It's hard to have any kind of real-world usage from just React. You have to learn and use some kind of Flux, routing library, AJAX patterns for that Flux library, another library for and , etc. If you want server-side rend…
You really don't need to learn some Flux to solve problems with React. React works fine without Flux, or really any formal data layer; you can comfortably use it simply as a really nice view library. I agree that people give up on React after tutorials that make them think about routing and Flux. It's a shame, because the core concept of React is incredibly simple, and anyone can pick it up in a couple hours. Flux is…
This, much more of this, please. I've been part of a small react project that was doing just fine without flux. Then the tech lead, a enterprise Java guy, decided we needed to use Flux because it was the "best practice". Problem was none of us understood Flux or how the project would benefit from it. It was pure cargo culting.
Needless to say the whole thing became a huge mess as we spent all our time moving data to the store and back into the components. What is sad is that if the project had been allowed to evolve naturally, we might have ended up with a poor man's version of a Flux architecture, possibly even using Flux as a guide. Instead we had to force the project into a Flux pattern we didn't understand and wound up with a mess.
Regardless, I have learned to associated the phrase "best practices" with some imminent cargo culting.
Re: React: Mixins Considered Harmful
#118React dropping mixins is the #1 reason why I stopped using Meteor. Sure Meteor has Blaze, but nobody uses it.
Before we had a nice mixin called getMeteorData:
``` var HelloUser = React.createClass({ mixins: [ReactMeteorData], getMeteorData() { return { currentUser: Meteor.user() }; }, render() { return Hello {this.data.currentUser.username}!; } }); ```
Short, simple, you knew exactly what it was doing without breaking your wrists.
Now it's some create container lunacy that brings no benefit to most projects except dogma "properness" - the developer UX is just fungled beyond belief and it makes me so sad that Meteor lost so much.
I guess my gripe in general with Javascript now is how complicated simple things are. It's entire ecosystem is intertwined with complexity and verbosity.
I wonder if typescript alleviates some of these pain points.
Re: React: Mixins Considered Harmful
#119React dropping mixins is the #1 reason why I stopped using Meteor. Sure Meteor has Blaze, but nobody uses it. Before we had a nice mixin called getMeteorData: ``` var HelloUser = React.createClass({ mixins: [ReactMeteorData], getMeteorData() { return { currentUser: Meteor.user() }; }, render() { return Hello {this.data.currentUser.username}! ; } }); ``` Short, simple, you knew exactly what it was doing without breaki…
> I wonder if typescript alleviates some of these pain points.
TS :> JS, not <:. What specifically are you hoping TS addresses?
Re: React: Mixins Considered Harmful
#120Implementing mixins correctly in JS (which React does not) is already a well explored problem space. I like https://leanpub.com/javascript-spessore for great explorations and derivations of various mixin patterns. It's not that mixins are bad in general, it's that React doesn't implement them well in particular.
Thank you!
The code in JavaScript Spessore is ES5-specific, but I stand by the ideas discussed, including the one central to TFA:
Naïve mixins solve the many-to-many dependency problem,
but not the open recursion problem.