What a disgusting reply. It’s clear that props comes from properties and mount from mounting. But maybe foreign engineers, such as myself and in the react team, should start checking slang too so they don’t fit into a particular, contextless agenda. From now on I won’t refer to pointers in C# classes no more.
That really lowered your credibility. And I have incredible bright woman engineers on my team and academia.
Sounds like you’d like Vue.js’s approach to components so; JS (Babel transforms), html (or Jade, Nunjucks etc.) and CSS (or Sass, Stylus etc.). While it has two-way data binding, you can utilise a unidirectional communication pattern much like React.
Regarding your brogrammer remarks, it’s very difficult to disagree with your opinion on this forum without being called a sexist pig, which is ironic as assuming I’m sexist because I’m a male disagreeing with a woman’s opinion like I’m not entitled to is in fact sexist.
I sometimes question your adoption of Meteor if that’s the case, as from reading your posts, it sounds like you’d be better served by an alternative framework or platform that wouldn’t require a fork, regardless of terminology (I refer to the technology).
When you accuse an API of being laced with profane and unprofessional brogrammer slang you better come equipped with a lot more better examples than just “props” and “mount” (neither of which originated with React).
…it seems to me that they don’t even need to be “stateful”. The framework (React) can handle all the side-effects of binding everything together and passing your functions everything you need–just like side effects is addressed in Elm with monads or (monadic-like solutions) and like Redux seems to address with “middleware”. So for example we could remove this before handleClick here:
export function render(props, state) {
return (
<div>
Clicked {state.count} times
<button onClick={handleClick} style={{ width: props.width }} />
</div>
);
}
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.
…actually I’m gonna create a new post that covers this in depth here:
I agree, with Redux you can pretty much eliminate stateful components. I’m hoping eventually React gets a more integrated version of redux and connect for ‘built in state’ and Redux could be reserved for more complex uses.
…actually I’m gonna create a new post that covers this in depth here
Stopped reading at “Anyhow mixing HTML, CSS and Javascript in the same file is quite confusing, error prone and very verbose compared to Blaze or Jade.”
I guess you haven’t really made a Blaze app past todo apps.
Serious guys using “props”:
Serious guys using “mount”:
http://man7.org/linux/man-pages/man8/mount.8.html
Maybe it’s a little bit off topic, but maybe some of you guys can explain me the different way of thinking when I use React. In the past, I’ve started any application with a ui framework like Bootstrap or Semantic UI. Both frameworks require jQuery and if I got it right, jQuery is a no go in React, because it manipulates the DOM directly. Now I try to understand how I would create an app with React when there is no stable ui framework available? I know there is a Bootstrap React edition, but it is still beta. So I have to search for single components, f.e a sortable table, on a npm listing site like react.rocks?
I’m asking this because when people say “Blaze is dead”, they would also say that ui frameworks like Bootstrap or Semantic are dead projects. Both are based on jQuery and with React we have to leave this way. This is a litte bit confusing to me because there are still a lot people who use this frameworks and B4 is coming out soon. Maybe someone could tell me if I got something wrong.
Wait, are you suggesting that Blaze is better than React in a small app like the todo app? I think if React is better, people will find it great even they have just done the todo app in React, no matter what the app size is.
Yes, yes, @SkinnyGeek1010 and others are implying that React shines when the application becomes somewhat large, due to its stricter data protocols and organization.
I’ve never used React or related technologies, but just reading these forums over these last few days I’ve come to see that:
Basically with Blaze data and organization it’s anything goes, which is easier to start but harder to organize and reason about if your application becomes large, while React restricts the way you input data, which is harder to setup up and requires more organization up front, but later if the application becomes large is easier to reason about, test, and debug.
In theory the React (data in from the top, no side-loading) restrictions reduce cognitive overhead by reducing variability (or choice). This has benefits in larger applications it’s said. Which is ironic, because Meteor was so easy to use last year due to this very point – the restrictions on tech at each level of the stack.
Yet with Blaze, you have many data and structural options. This makes it super easy to get going quickly and allows you the flexibility to do things in an unorganized manner if you so choose. The theory goes, that once the application becomes lager, things can become unmanageable if you’ve not organized properly.
My application is larger, yet since I’ve properly named my directories, files, templates, session (both global and template level), functions, etc, I never felt the cognitive overhead some have mentioned. When I get an email from a client stating there’s a problem, I know exactly where to go in the code to fix the issue without much if any trouble. But this might be because I’m the one that wrote the entire application. If I had developers working for me, I might need to document and lay out best practices. Maybe it would be harder for new developers to become productive using Blaze instead of React.
Not necessarily. I use jQuery in one of my React apps and it works fine. You just can’t mutate the DOM underneath it or React gets confused. Typically i’m using it for parsing a form or using those popover hover things. The Bootstrap modal might get a little tricky but you can always get a React bootstrap modal on NPM easily.
Semantic seems to play nicely with React too!:
Semantic UI components are designed to be compatible with libraries that tightly manage UI lifecycle like React. No special bindings are needed.
http://semantic-ui.com/introduction/integrations.html
If you really need jQuery or Blaze to ‘take over’ the DOM, you can just ‘quarantine’ an area and tell it to not update and React will leave it alone, allowing you to mutate that area as needed manually.
In general jQuery requires that you imperatively change the DOM as in step 1 do this, step 2 do that, insert this DOM node here, hide that one. In this case it also frequently relies on the DOM to be in a certain way (classes/ids) which can be brittle. Where as a declarative paradigm only requires you to determine what the end result should look like, and under the covers it will make the changes needed to get the end result. Historically this has produced more bug free code and is easier to maintain (in general).
Interestingly Blaze has a declarative paradigm like React does but Blaze also allows for a nice seamless jQuery integration so a lot of people (including myself) just fallback to old habits and write imperative code to do something… as writing declaratively takes a lot more effort at first if you’re not used to it.
A good example of this is the ‘current tab’ of a navbar. Most people would just sniff the url and let if fall down through a case statement and use jQuery to add the ‘active’ class to the correct tab. This works until the designer changes the classname. However, with Blaze you can just set a Session or template var and use a template helper to consume it which would output 'active' or ' ' depending on the current page.
It depends on what better is. If you can iterate much more quickly with Blaze and find less organization to be a good thing then yes. However, personally I would just use React for small apps as well. I’m faster with that than Blaze at this point (lots of tab triggers) and I have a basic boilerplate to create a hello world app in a few seconds.
You can use jquery. Just don’t do any Dom manipulation on react managed components, i.e. removing ‘divs’, without telling it first to not update it anymore. If you’d wish you can still change properties, add css classes and even add notes. React won’t care.
Role of JQuery
One of the reasons jquery came along was because it took too much time to load a newly generated html file from something like a php server. Back than, you needed to decide if you generate the html on the server or rely on changing it on the client.
Role of React
React is basically your incredible fast static html generating server right in your browser, reliably much faster than incremental Dom manipulation. However, that does not mean you always need to do that. If you have a nice jquery plugin that you don’t want or can’t migrate, just turn of handling for that section, and keep using that slick jquery slideshow as you normally would. Even that blaze template.
Working with other Libraries in React
I.e. Bootstrap is mostly about scaffolding and styling. Css styles and html boilerplate. Most of the JS even just adds or removes a css class from an existing element (because “display: none” is faster than deleting nodes). No problem. Just for the JS features that really add and/or remove elements you need to decide if you want to manage them with react or if you keep them as is: Unlinking the element from react. Preventing component updates is something that you can do and undo in any moment for the smallest to largest node.
I call that the decision between working in “Rendering-Style” vs “Static-Style”. Both has pros and cons. Flexibility in using legacy libraries vs. speed, server side rendering, predictability and testability.
Example
The question of how hard it is to incorporate react into an existing workflow brought us from an experiment to Touch2S. A basic Meteor App that uses React, Framework7 (a mobile framework that even uses “its own version” of JQuery) and Webpack. The result is server side rendering and no ambiguity in the development workflow.
I’d advice you guys to just clone the repo and try react after reading Working with Touch2S, React & Framework 7. Maybe than you’re not so scared anymore. React is just a rendering engine.
D.S.
Hey that sounds like a great project!
Here are my thoughts and insight regarding the offense to words used in React–for what its worth, I’ve been a long time dancer / bboy and have heard it all.
The following mean “awesome” or really good: bad, phat, fresh, dope, sick, insane, nice, nasty, wicked, etc. and you can add f**kin before those words to make it just that much more effective.
Surely UNIX “mount” isn’t offensive.
“Props” is a funny word. It had its run in the 90s. It means “pay respect” and no one who knows how to use the word gives “props” for a sexual act in itself as implied by Urban Dictionary. Its more like
“Yo, I noticed that you’re flares are really high in the back, if you could pull up all the way and front-handspring out of it, I’d give you crazy props”
translate:
“You’d have my admiration if you could perform [stated] acrobatic maneuver”
I’ve never once heard a guy “give props” to a guy for sleeping with a girl. Meaningless fluid exchange isn’t admirable. If fact, there is another slang “no easy props”, which means to “my admiration isn’t for sale or easily devalued”.
Example in actual use, see bottom left logo, the branding tries to say “we’re all about earned respect”:
So as for Clinical Meteor, I’ll give you mad props when you branch it and show MDG what’s up; but no easy props until then 
Anyway Facebook is corny. Silly website IMHO, but cool tech. PHP “hip hop” is another attempt to be “cool” or whatever. Also you’d think React and especially GraphQL would have better logos. That said, React is actually pretty cool in that it brings functional programming ideas in languages like Haskell to a front-end framework:
This isn’t the work of a “brogrammer”–it is well thought out engineering.
Y’all are over-reacting and arguing for the sake of arguing. I know exactly were the terms come from, where the slang comes from, their history in the IT industry, and am not saying that it’s unprofessional for your all’s industries or workplaces. I’m simply saying that those terms are borderline for the industry I and my clients are in.
All things considered, React syntax is fine for most needs. It’s just got a few rough spots where Facebook company culture is apparent, and doesn’t align with other industries. Hoodies versus business suits.
(And since I’ve put the time and effort to put together an industry specific release track together, it’s my prerogative to clean up APIs according to our needs and advocate for others to do the same. My clients wear business suits, lab coats, and scrubs, after all.)
For what it’s worth, I’m refining the process for advocating for syntax changes that some people might find problematic, and think that dropping urban dictionary links in threads seems to be a good approach going forward. Minimum of commentary; but objective reference to how APIs can be taken out of context.
Relax. It’s constructive criticism for making React more accessible to more industries.
I don’t think you were wise to pick the word ‘disgusting’. Hope you can see that.
@awatson is a valued member of this community. It’s fine if you don’t agree with her. No need to get personal and call her labels (unless you are the one who picked the terminology synonyms she is telling us makes her uncomfortable, in which case she kind of started it). This is not your living room. No one gets to tell you what you should feel comfortable with, nor do you get to tell others what they feel.
So far awatson has been called sexist but no one else.
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.