The higher order function example in ES6:
React: Mixins Considered Harmful
191–200 of 205 posts
Re: React: Mixins Considered Harmful
#192Earlier quoted context omitted.
Higher order functions are not such a complicated concept. Just a function passed to a function. You use functions, right?
Yes, but why is the question. I think that is seriously not given much thought and people just accept man-made complexity as essential. It seems tautological to say that higher order components extend components, but it is only due to the design decisions of the React authors that application code must fit its own paradigm, not the other way around.
On the contrary, it's about reducing complexity. You don't have to worry about mixins, classes, prototypes, inhertiance. Just plain old functions. Can't get simpler than that.
Re: React: Mixins Considered Harmful
#193So there are a lot of features in React that are basically getting deprecated, like createClass in favor of ES6 components, mixins, etc. This is good that you guys are learning as you go, my question is will you ever release a version of React, possibly spin React off into a version which supports deprecated APIs and a version that doesn't and is therefore smaller, faster, and easier to maintain? Eventually you could…
We are not deprecating `createClass()` yet. When we do, we will keep it for another major version (just like we always approached deprecations) and then move it to a separate package so only people who really want it would use it.
Yeah I was just using createClass as an example of a feature that's not strictly necessary and could be removed to slim up the library. Thanks for responding! Any idea when you will be trimming stuff like that out? Do you think you will you ever remove mixins?
Re: React: Mixins Considered Harmful
#194I like how core features of React are being considered harmful. First it was component internal state, now it's mixins and next thing will be the lifecycle methods. React components will then boil down to pure render functions. React will then be replaced by simpler VirtualDOM implementation. JS function declaration boilerplate will be removed from render functions, so they will be more HTML with some JS as the other…
As many others here have already pointed out, component internal state as a general concept is not by any means considered "harmful" and can often be quite useful. I was part of an open source component library project at my company where we used internal state for a number of those components to handle state that was likely to be unimportant to any consuming application.
For example, our component equivalent of a drop-down menu has internal state to deal with whether or not the menu is expanded or not. This is not likely to be state that a consumer cares about -- all anyone really wants to do with this is pass in which menu item, if any, has been selected and to know when someone selects one of those options.
Re: React: Mixins Considered Harmful
#195Awesome post Dan, thanks for writing and sharing! One thing caught my attention: >At Facebook, we extensively use traits in Hack which are fairly similar to mixins. Nevertheless, we think that mixins are unnecessary and problematic in React codebases. Here’s why. >Mixins introduce implicit dependencies >Mixins cause name clashes >Mixins cause snowballing complexity When I read these three reasons, I actually felt ide…
Traits and mixins are different. A trait/interface/protocol doesn't generally contain implementation, and when it does, it is based only on other methods in the trait (for things like default implementations), whereas mixins are just fragments of a class implementation with potentially arbitrary dependencies on methods. So traits document the dependencies that mixins make implicitly. Traits in typed languages can onl…
Thanks for your response.
I can see how type checking helps with that in Hack, that makes a lot of sense.
Guess that in the case of Ruby for example we'd still have the same disadvantages as in JS right? Since there's still the possibility of calling methods in other modules and even in the class where the module is included, since that is discovered at runtime and you don't have any hierarchy that restricts who can call what.
Re: React: Mixins Considered Harmful
#196Earlier quoted context omitted.
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 hope this helps: dispatch(action) { this.setState(prevState => reducer(prevState, action)) }
Hmmm, that'd be sweet in a mixin...
ducks
Re: React: Mixins Considered Harmful
#197Earlier quoted context omitted.
I can't speak for the community as I've been using React/Flux for under a year, but I think that Redux and other Fluxes serve a very different role from component state, and using Redux/Flux to store all your state will cause problems with both performance and code complexity. Redux manages the state of your application as a whole. But individual pieces within the page have no reason to know about the page state. Lik…
My observation is that going with local state is going to bite you sooner than later and in most cases having it in Redux Store from beginning is a good idea.
I recently made a slider in React/Redux. Imagine a slider that has a width of 200px but needs to report values from 0 to 100. (The width is governed by external factors, e.g. other sliders nearby that need to report a widger range, but must visually be of the same width.) This means that sometimes you may move the slider just by a pixel and need to register the movement, but the underlying value won't change. I.e. you have the slider offset and the actual value.
The slider offset is a very transient variable that is not really important. Next time you load an object from the database you'll just convert the value to a slightly different offset and nobody will notice. Are you going to store the offset in the big store?
Re: React: Mixins Considered Harmful
#198Earlier quoted context omitted.
We are not deprecating `createClass()` yet. When we do, we will keep it for another major version (just like we always approached deprecations) and then move it to a separate package so only people who really want it would use it.
Yeah I was just using createClass as an example of a feature that's not strictly necessary and could be removed to slim up the library. Thanks for responding! Any idea when you will be trimming stuff like that out? Do you think you will you ever remove mixins?
We don't need to remove mixins because that's one of the biggest reasons people use createClass(). So it's enough to just separate createClass() and then we wash our hands, and it lives its own life. We won't use it but others are free to if they like it.
No specific timeline but we might I'd say within half a year is likely.
Re: React: Mixins Considered Harmful
#199Earlier quoted context omitted.
I had an impression, that React community (not the authors) considers Redux as an best-practice. My first post was a little bit exaggerated view on where is this whole React-based website developement (including Redux and other libraries and tools) going, not only the React itself.
>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…
The majority of developers don't have the time or interest to dig deep into nitty gritties of the React community & ecosystem. They read articles including yours and quickly become indoctrinated into thinking how (for example) putting ALL state into a redux store is a proper way to work with React.
This leads to hilarious codebases where people dispatch actions in order to update input values or navigation dropdown open/closed states etc. Trivial apps that could be built over a weekend end up taking weeks to finish.
It's a sad reality but most people (including developers) take everything they read at face value and don't devote enough time to critical thinking. We should try to combat this.
I'm not saying it's your fault (it's not, you're great), but perhaps you should put a bit more effort into stating how what you're propagating is just one way of writing code and shouldn't be used in all situations (especially simple apps). I've actually seen you do that in a couple of places in the past few months and that's great.
I do feel a bit bad about sitting in my chair criticising while you're contributing with all this awesome stuff but you know... with great power comes great responsibility :-)
Re: React: Mixins Considered Harmful
#200Earlier quoted context omitted.
> easy-to-reason-about redux-style state reducers This buzz phrase "easy to reason about" is so popular in the React world. I feel like I'm the only one who finds it oxymoronic. Especially with regard to Redux, which I think is anything but. Angular 1/2, Ember, Backbone are all pretty "easy to reason about", so much so that it is rarely pointed out.
You are definitely not the only one who has not found Redux "easy to reason about". I think the concepts are somewhat straightforward, but in practice are a little harder to grasp, especially in real world applications.
> the concepts are somewhat straightforward, but in practice are a little harder to grasp, especially in real world applications.
Well said.