Coincidentally I came across Deku recently which has already codified this pattern in its library. A Deku Component looks very similar to @SkinnyGeek1010’s stateful module example. Deku doesn’t use React, but has a very similar API. It has examples using Redux for state management, which actually seems more in line with what @faceyspacey mentioned: [quote=“faceyspacey, post:27, topic:15667”]
The platform passes in state instead and ideally gets it from a single source of truth atom, thereby removing the requirement that components maintain any of their own state. Or, simply passes it in as props just as Redux does via “higher order components”–and for event handlers passes in the global state atom in addition to the props of the corresponding component.
[/quote]
Surely a lot of this will inspire future developments in React.
@SkinnyGeek1010 has explained it really well (as usual). I’ll only add this video as a must-watch – Pete Hunt explaining the design philosophy of React when it was quite new. Especially look out for the part where he talks about “separation of concerns”.
The way I’d put it:
The traditional MV* frameworks led us to use technology (html, js, css) as the criteria for separation of concerns. React lets you overcome that with its “component”, which is all Javascript but provides ways to cohesively bind the other technologies for the same “concern”. Here, the “concern” is a part of the UI and it can be the most basic part (dom elements) or having arbitrary level of complexity (larger components generally composed of smaller ones).
As far as noobs are concerned, it’s much more difficult to unlearn than learn something new! They’ll fortunately be saved from unlearning the same things we had to. But then, they’ll have something else to unlearn in a couple of years
The poster didn’t give reasons in the lines of “it being offensive”. Anyhow, I think his/her original reasoning is not right either. Like I commented there:
I don’t think componentDidRender is a substitute for componentDidMount because the component can render multiple times when props change after it’s mounted once.
Anything unfamiliar seems more difficult. I’m sure as and when React becomes a first-class citizen of Meteor, it should be a lot more easier to use it with Meteor than today. Not to forget the tons of work happening within the React ecosystem, outside Meteor.
The difference is not dissimilar to writing everything in a single PHP script v/s using an MVC framework. With time, it will only get easier to get started with “the right way” option.
This kind of discipline and structure would always be needed; the importance increasing with the size of the project. React or any framework can make a few things easier, but there can be no substitute to good project organization and communication within the team.
We could probably come up with twenty synonyms for any element of an API. We pick these two, and maybe they would be the top choices for a small percentage of us here, and maybe no single choice would break 50%, and it’s not a democracy. The donors get to name it.
But that wasn’t done in a vacuum! I don’t think either word is a shining example of clear meaning, nor that either wouldn’t get a Beavis and Buthead reaction.
Someone pointed out they are already terms in use, so I pointed out non gender related criticisms. Props is the only long term with an abbreviation I notice in the API, and you could both argue against abbreviations, and against the pluralization of that one. .prop.key is better than props.key to me.
But boy (heh) did they get strong defenses. I only chimed in when it seemed to be a pile-on, cherry picked from a well reasoned series of comments by a valued contributing member of this community. Those terms didn’t strike me as offensive, either, but since when is that the question? The first time an Asian pointed out to me that it’s rugs that are Oriental, I got it! Why do we need more in a professional environment?
‘I am not offended by X therefore…’ Is not a valid logical construct from which to reason about anything.
That is the kind of thing that makes people feel unwelcome. But it’s 2016. Let’s leave that in the past.
A large opportunity for technology projects is to reduce the learning curve in order to make technology generally accessible. Simple, accessible technology allows many people to express themselves and participate in the evolution of our ideas.
Agendas beside, I see react as the solution to meteors current problems. Opinionated structure, server side rendering, testability, getting rid of maintance overhead for blaze, re-joining a large web-dev community …
To argue to withhold the switch to react because something better will come out in the future is generally bad practice. Take a look at the problems you need to solve and than pick the framework. Don’t judge based on todo apps, look for features.
For example, we love react because we often have infinity lists (virtual list scrolling) of many thousand items. Due to the virtual Dom properties, we can render those much better than we ever could with blaze. Do we need 100% functional programming with lisp like om next for that? I don’t know yet.
I think the decision to choose the names they did might be affected by the kinds of dilemmas I face when naming things in my code. Explicit names, but not too long either. Especially with camelCasing, you really don’t want names that are very long. Hence props makes sense to me, since it had to be part those lifecycle methods too. I think there would be many I know who’d slightly prefer componentWillReceiveProps over componentWillReceiveProperties (ideally something even shorter if that made sense).
But a name had to be chosen, and it’s done. The only possible way I can think of to have everyone’s nod of approval would be to publish an RFC and involve everyone in the process. But then, perhaps React would still have been in the draft specification stage and we would have been arguing about what should be chosen, instead of what’s already chosen. I like neither, but if I had to choose one, I’d choose the latter so that I can ignore the arguments and focus on using what I have
As far as the pluralization is concerned, I think it makes sense for an associative array. props is a more of an associative array than an instance of a Class (when singular would have been appropriate).
I agree (assuming my understanding matches what you intended ). Hence I hope you realize that chiming in for whatever reasons might be misconstrued as taking sides and potentially stretching the digression. I admire @awatson1978’s contributions to this community and I think she’s capable of responding for herself and she’s already done so.
Btw, not taking any sides here, but I’d like to present a perspective since I got involved somehow… I wasn’t aware of a single slang meaning of the word “props” present in urban dictionary (maybe because I don’t reside in US, or the slang hasn’t caught up yet in India, or I’ve been inside my cave for too long).
While we definitely don’t want any words in APIs that are obviously offensive, we shouldn’t be cynical either in judging their origins/motives. Most slang varies from region to region, and we have developers from every corner of the world. So it might not be fair to expect nor feasible to define API names that please everyone.
Heh… And truthfully, a lot of the terms in Javascript ecosystem (including the official Javascript API) will get similar results on Urban Dictionary. So, I am not so sure Urban Dictionary is the best barometer for what is appropriate or not.
It’s certainly feasible to use jQuery with React like @dinos and @SkinnyGeek1010 have already explained, and I’m using them together in my projects too. But there are some UI toolkits in the horizon, that remove/avoid jQuery and use only React for their implementation:
@awatson1978 is free to voice her opinion on which words she finds offensive, but I think people here should remember nobody is forcing them to argue with her. Let’s stop derailing technical threads with this “debate”, it’s becoming a bit ridiculous (on both sides).
And regarding React: even if you don’t like it I think it’s quite clear that all the smartest web people are gravitating towards it. If there’s one thing I’ve learned in the last 3 years working with Meteor, it’s that momentum is everything.
I gravitate to @awatson1978 general overview and the comments of a personal and youthful approach in the tech world, where there is lack of consideration for circumstances and long term vision, for a more egoistical, cocky approach aided with some God given fortitude in intelligence for programming something “cool”.
I don’t care if she’s the pope - her statements are sexist, so I’ll be more than happy to call her out on that, so she (hopefully) can improve her submissions.
I feel like I’m speaking for other users when I’m saying I want her bright insight into software to be posted, and not thoughtless rants about how “props” or “mount” is unprofessional terminology… Not to mention all the other things I’ve read from her over the last few months I’ve been here… It’s just plain wrong, and should definitely be said rather than ignored.
Let’s end it here, and if you feel like there’s more to say, please, submit a new thread, and mention me there, as I’ll be happy to help you see my point of view.
First, that is about the most polite way anyone can possibly say “Just ignore her” that I can imagine.
Second, her post was on topic as are the replies. This thread is about What is wrong with React, and how MDG can fix it… @awatson1978’s is saying that React has unprofessional lexicon that causes heartburn for her clients and perhaps MDG could help improve the lexicon.
It’s no mystery why @awatson1978’s comments on this topic garners disproportionate attention.
You have to contort your mind into a pretzel in order to find the examples provided to be unprofessional. this.props and componentWillMount is really nibbling at the extreme edge of the unprofessionalism spectrum, if it is on the spectrum at all.
She is proposing or implying that the API be changed to suit the sensibilities of a few individuals in one industry in one country, and many find this to be unreasonable, especially given #1 above.
So, combining those factors, people take serious umbrage with the implication or possibility that they should be made to do more work and rework their codebase to suit her clients’ unreasonable sensibilities.
Purely from an effectiveness perspective, IMO it makes a heck of a lot more sense for @awatson1978 to fork the libraries and substitute her own industry specific language. If there is actual abundant outrage over the language, she’ll have no problem finding people to help maintain the forks or charging her clients for the labor. Or better yet tell her clients, politely, to get over it.
So, we are programmers, and able to parse words carefully and understand their meanings until things get emotional/political. Then all bets are off.
No one has said those words are bad, so no need to defend them. That is probably a straw man argument. I would characterize @awatson as saying those are ‘Brogrammer’ choices, which kind of means here that they are chosen from among many better synonyms for their sexual nature. Deliberate double-entendres. It’s never happened to any of the ‘helpful’ guys here, but in some workplace somewhere, some creep now gets to carefully give just a little emphasis on MOUNT when looking at some female programmer, and it’s all smirky, and everyone gets what is being said. And 100% defensible!
After pointing this out, amid a stream of sophisticated comments, after being told the blaze camp is just a bunch of todo app programmers:
We’re also judging it on W3C standards, quality of the API, existing tooling infrastructures outside of Facebook, and different market needs.
React breaks color coding standards in editors; the ‘props’ and ‘mount’ verbiage sounds like brogrammer gutter slang, we can’t scan/reuse HTML templates in non-react pipelines, web components aren’t being exposed according to W3C standards, and while the static imports might be great for file load ordering, they’re brittle and horrible for discovery-based application design.
The BlazeReact package solves most of these issues.
Here are some quotes she gets told:
Get your mind out of the gutter
your sexist attitude toward male programmers
disgusting reply
very difficult to disagree with your opinion on this forum without being called a sexist pig
I sometimes question your adoption of Meteor
laced with profane and unprofessional brogrammer slang you better come equipped with a lot more better examples (YOU BETTER? not in evidence: profane, unprofessional)
A large number of comments that parse down to either “those are not naughty words - look someone else uses it in a sentence” or “what words haven’t been used to imply something else” or “I was not offended by those words”
@Sacha, you have now chimed in. Please help me see which comment either aWatson or I made which is ridiculous. Please make sure to experience them in context of the threading.
Are you one of the programmers she is calling a brogrammer? If so, I can see why you want your day in court. What has she said that is sexist? Help me see your point of view. Or, what was the thoughtless rant?
Can you guys/girls open a dedicated thread to talk about sexual discrimination in software industry and political correctness so we can re-focus on “MDG React” please?
). Hence I hope you realize that chiming in for whatever reasons might be misconstrued as taking sides and potentially stretching the digression. I admire 
