Yep, bought a couple as well. I know what goes into integrating them. It’s hell and tedious.
I guess I’m wondering if you have tried just using jQuery inside componentDidMount just like you would in onRendered in Blaze?
3 Likes
Yeah it works just fine. 
Just remember in React to always always always work with the state. Never directly manipulate the DOM.
can you show me something you designed yourself on par with what I can buy on theme forest?
something with this level of detail:
http://www.keenthemes.com/preview/metronic/theme/admin_1_rounded/
How much time do you think would be needed to deliver such a product when designing from zero? In man hours.
No, do you think it would be that simple?
Depends on what the jQuery is doing.
But basically what I’m trying to say is, when using the theme you’re going to be rewriting a lot of HTML anyway, so it’s not like its 0 work to use Blaze or Angular. I think it would be just a little more work with React. But I could be wrong.
5 Likes
I just use Bootstrap 3 and the relevant designer on Team X makes it look nice. I’m not really a designer. I imagine that making something like a purchasable team would take a few weeks. But maybe not, it’s all just CSS really. With some freaky JS sprinkled about.
React can be tricky with some large jquery libraries, like sliders for example. If the library is adding a lot of things to the DOM, there can be some unpredictable funny business, for example, invariant dom manipulation errors , that you gotta lookout for.
But if you keep your jquery code inside componentDidMount as @sashko said or inside event handlers, there is usually no problem.
Sometimes I find that I need to wrap jquery methods in a zero second setTimeout to wait for the callstack to clear. For example, the following code is in a method callback I have:
if(res.status === "error") {
this.setState({saving: false});
this.setState(res);
Meteor.setTimeout(() => {
$(".modal-body-scroller").animate({ scrollTop: $('.modal-body-scroller').prop("scrollHeight")}, 1000);
}, 0);
}
Here I am setting the state, and the UI is being updated elsewhere in the code, but I need to wait for all that to finish so the error messages are rendered before the UI scrolls to show the error messages. Without the setTimeout, the jquery fires before the DOM has finished rerendering with the error messages and the animation doesn’t work. Is this how other folks do it?
Anyway, between these little tricks, i don’t have too much trouble with jquery and react aside from certain libraries that add and destroy a lot of things in the DOM.
I’ve actually encountered a couple of admin themes on themeforest with official Meteor support… Beyond that, I think Semantic is a lot better than any of these themes… But that’s just me.
this is basically a race condition, which is a complex problem to solve, and has no one way solution.
It stems from the fact that the lifecycle of a page radically changes with reactivity. In the old web once you loaded the page and it rendered you were fine, changing the data meant refreshing the page, so onRendered had a specific meaning.
With reactivity the pages goes through many small changes, with the events called multiple times. We need to shift our thinking, adopting new paradigms very much like they had to do with the advent of SMP processors.
Anyhow someone more pedantic than me would say that the easiest and mathematically secure solution would be to use a lock, which starts by default as false and become true as soon as the first library call spawn.
What about React components which I can install via npm (like a slider component). Wouldn’t it be better to use such a component instead of a jQuery library? I’ve never used React before and just wondering why people still need jQuery plugins like sliders when there is already a component for it.
1 Like
Yeah, you’re right. If you can find one that works for you, that is 100% the way to go. But, I’ve found, especially when you need a lot of control over the slider, that the implementations lack the same flexibility of the their jQuery counterparts. But that has everything to do with my own use case, your mileage may vary. 
1 Like
Ahh okay, I was just asking myself if components reach the same quality/functionality like jQuery plugins which are longer on the market.
maybe you are porting existing software?
It’s funny, all the people who are thinking react is not better than blaze(in this forum and this thread), have not used blaze past 1 person medium sized project.
While pretty much everyone who used BOTH blaze and react extensively from 1 person to a team and from small to large size project ALL prefer react.
It feels like feeding the trolls when you are trying to explain the benefit of something to someone who hasn’t even have the experience of using both technology.
How can you explain the benefit of a car to someone who has never left his house?
What’s more annoying is that most of all the argument for blaze are mostly all very self-centered, aka
MY project is in blaze it will take too much to port over
MY designers cannot understand react
I dont ever want learn anything but blaze
…etc
But if you are listening to what the react(or other non-blaze solution) advocators are saying, they mostly always acknowledge the benefits of blaze while disagreeing with how blaze won’t be a fit for a future with complicated apps and how other libraries does it better. And most importantly, these people think about the future of Meteor, they care about it being more open to the rest of the JS world.
Another question is this: even if MGD kept developing meteor, you really think you will be using it 2 years down the road? With the fast pace of the front end there is no way MGD can keep up with the npm ecosystem on frontend UI frameworks with the people who are dedicated to improve it. Why not leave it to the best?
I think this level of complaining is also exacerbated the fact that Meteor has drawn in newer developer who has never learned more than 1 language, and is literally being spoiled by the everything-being-fed-to-you and walled-of-garden style of the meteor world.
Meteor is not the only one who is experiencing growing pain, pretty much all other frontend framework(and libs) in the current age JS world has huge API churn:
Angular,
Ember,
etc
There are new languages being made just for coding the front end: http://elm-lang.org/
Why ?
Because Javascript AND HTML was not made to do what it is being used today: Fully interactive dynamic Applications
Which makes me bring up the argument for Html templates. I just want you to think about this for a second:
Do you see anything remotely similar to HTML/templates in other domains that require heavy UI development? Desktop computing? Gaming? Mobile Apps?
All of the UI elements are baked into the native programming language in other domains.
Why? Because separating logic and markup is NOT separating the concern, they are both concerning the SAME THING: the UI. This is not 1990, you dont make web pages anymore, everything you design will be interactive, it will be tightly coupled with logic, separating them is breaking up two things with the same concern.
Also, you seriously think HTML template is the way to solve what we need to solve in the future of web applications? You think a {{#each}} and {{#if}} is gonna be enough for the coming years?
You see, this whole thing is not about what your project or your company does, it is about how Meteor is going to stack up against the rest of the JS world. It is about why rest of the world haven’t started using meteor yet, and how we are going to grow as a community.
And step one is not trying to do everything from backend and frontend all yourself.
4 Likes
It’s funny, all the people who are thinking react is not better than blaze(in this forum and this thread), have not used blaze past 1 person medium sized project.
While pretty much everyone who used BOTH blaze and react extensively from 1 person to a team and from small to large size project ALL prefer react.
That is completely inaccurate and entirely not true. You can’t make a generalization like that.
It feels like feeding the trolls when you are trying to explain the benefit of something to someone who hasn’t even have the experience of using both technology.
I don’t understand why anyone would care if someone else prefers one thing over another. Just let them. So what if they don’t like the same thing you do. Don’t take it personally. I’ve noticed that there are quite a few people making assumptions about other developers and their teams based solely on their preference.
Someone doesn’t like React? That doesn’t mean they are incapable of learning or unwilling to put in the time. It doesn’t mean that they are uneducated. It doesn’t mean they are selfish.
Someone likes Blaze over React? That doesn’t mean they have only worked on a project by themselves. It doesn’t mean that they have only worked in small teams. It doesn’t mean that they must write messy code.
Someone has concerns over porting their app to React? That doesn’t mean their app was designed poorly.
I have seen all of the above deprecating comments made towards individuals or about individuals based on, God forbid, their preference in a UI library. Please stop.
6 Likes
It sounds like it has little to do with the industry you’re in and more to do with what your personal sexist views are.
Any programmer would understand clearly that “props” is short for properties. And unless your client’s doctors, surgeons, and executives are reading your Meteor application’s code, I highly doubt they will ever know about the “oh so offensive” use of the word “props” - that, by the way, is part of the API’s that keep their systems scalable, performant, and running smoothly.
Please tell me if your clients and their bosses explicitly read the code.
If they do: great, you have some slightly competent clients who I’m sure will understand what “props” is short for.
If they don’t, which is likely the case: grow up.
Ooh! We were talking about using themes from the internet, this might be helpful:
7 Likes
Does anyone know text analysis? I’d like to know the ratio of comments containing 2 or more insults/jabs against the subject matter of the original note. I can’t even remember reading any before this thread. There must be really threatening ideas being raised!
We just don’t like petty excuses for not using a perfectly able system.
Maybe you do.