"I missed my ex bad. My family and friends were tired of me being so upset one of them actually ordered a Love Spell for me From Extreme Spells I had no idea what they had done. They ordered the GLOBAL LOVE SPELL as it your best and most powerful and effective Love Spell. Needless to say, I was shocked to see my wife at the door a week later with her eyes full of tears, .I cannot believe how well my spell worked. I recently ordered a Money Spell because who doesn't need extra money?" quickrevengespell@yahoo.com -- William, Nashville
React JS Best Practices
81–90 of 92 posts
Re: React JS Best Practices
#82One of my initial problems with React & CSS was styling :hover etc. For now, Radium [0][1] solves this problem, but IMO as a community we're still trying to figure out all the best practices and patterns, when it comes to building isomorphic webapps (or webapps is general, since React introduces new way of building apps and I'm sure that's just the beginning). [0] http://projects.formidablelabs.com/radium/ [1] https:…
Using inline style for everything like Radium does is going to be much more expensive than using stylesheets.
Re: React JS Best Practices
#83Earlier quoted context omitted.
Oh holy shit I just moved my app off of reflux and on to flummox and wow! Much better
For the past one month, I've been working on an app in Reflux. If the benefits are significant, I'd surely look at switching to Flummox. Care to point out how the switch has been useful to you? Thanks!
I like very much that the API is more "standard" (reflux, imo, has some strange patterns) -- also, due to the ability to instantiate every aspect of the pipeline, you get isomorphism for free, and testing is much, much simpler.
Also, can't hurt that the library was designed and implemented in ES6, which is what I've begun moving our architecture towards!
Re: React JS Best Practices
#84Earlier quoted context omitted.
Oh holy shit I just moved my app off of reflux and on to flummox and wow! Much better
What would you say the major differences are with Flummox? It looks pretty straightforward but Reflux seems pretty lightweight as well. Just trying to figure out if it's worthwhile to switch an early stage project over.
I would say that Flummox is a slightly more verbose Reflux, written in a way that is somewhat more future proof and adaptable to change.
Re: React JS Best Practices
#85Earlier quoted context omitted.
Oh holy shit I just moved my app off of reflux and on to flummox and wow! Much better
I'm also curious to hear why you like Flummox better than Reflux. I'm using Reflux now, and haven't hit any pain points, which I can't say the same about some of the other Flux implementations.
When I started investigating isomporphic strategies with Reflux I stumbled upon this thread (https://github.com/spoike/refluxjs/issues/144) which made me realize that if I didn't switch quick I would have some terrible technical debt on my hands in the coming months. I started looking for alternatives and found Flummox, which is lightweight, isomorphic, and written for the future via ES6-7 features like async await and classes. (Once you start using ES6 classes with ES7 classProperties turned on via Babel -> stage 0 you'll never want to go back to the old way of writing things.)
Re: React JS Best Practices
#86> Flux is also quite verbose, which makes it inconvenient for data state, state that is persisted to the server. We felt the same way, until we moved away from Facebook's Flux implementation and adopted Flummox[0]. It's singleton-free, so we gained isomorphism for our application with only a tiny bit of extra work, and it hides away the dispatcher (unless you need it, which we haven't despite having over a dozen stor…
Has anyone built their app using ES5 and Flummox? The Flummox documentation is sparse to start and is completely devoid of ES5 examples. Edit: grammar.
Why not write in ES6 and transpile downwards to ES5? You're just fighting the direction of the wind otherwise. ES6 feels much, much nicer to work with in nearly all ways.
Re: React JS Best Practices
#87Earlier quoted context omitted.
What do you think of http://www.basscss.com/ and would this kind of CSS be helpful in the situation you described?
This is the first time I saw Basscss, so take all this with a grain of salt. It seems well written, but I would put it in the same/similar category as for example Bootstrap. Basscss seems to be more modular - you can build your own "version" of Bootstrap - but Basscss gives you npm modules, so you could do something like/equivalent of require(basscss-grid). So, there are some differences that can be interpreted as a…
BassCSS is very different from Bootstrap or any other CSS framework. It's more like "classed inline styles", so you build your element styling like 'border border-blue blue bg-white p1 m1' (blue border, blue text on white background, 1 unit padding, 1 unit margin) e.g. you mix-and-match different CSS classes to style your elements.
So, I was thinking using React + BassCSS, and build the class string in my React components. Not sure if it makes sense, but at least it would probably be a bit more manageable and faster to develop than inline styles. Inline styles could be added on top of that of course.
Re: React JS Best Practices
#88Earlier quoted context omitted.
This is the first time I saw Basscss, so take all this with a grain of salt. It seems well written, but I would put it in the same/similar category as for example Bootstrap. Basscss seems to be more modular - you can build your own "version" of Bootstrap - but Basscss gives you npm modules, so you could do something like/equivalent of require(basscss-grid). So, there are some differences that can be interpreted as a…
BassCSS is very different from Bootstrap or any other CSS framework. It's more like "classed inline styles", so you build your element styling like 'border border-blue blue bg-white p1 m1' (blue border, blue text on white background, 1 unit padding, 1 unit margin) e.g. you mix-and-match different CSS classes to style your elements. So, I was thinking using React + BassCSS, and build the class string in my React compo…
If that's the case, I stand corrected. But the thing is, I still consider Basscss a solution from the "CSS world". React, IMO, takes it to the next level and combines inline styles with JS features (simple example: https://youtu.be/7YwmS0ny-58?t=58m38s - the scalable font can be done in pure CSS but I could imagine more complex use cases). Still, everybody picks the tools that are best suited for the problem and his/her preferences.
Have you checked Radium (http://projects.formidablelabs.com/radium/)? What don't you like in this approach, if I may ask?
Re: React JS Best Practices
#89One of my initial problems with React & CSS was styling :hover etc. For now, Radium [0][1] solves this problem, but IMO as a community we're still trying to figure out all the best practices and patterns, when it comes to building isomorphic webapps (or webapps is general, since React introduces new way of building apps and I'm sure that's just the beginning). [0] http://projects.formidablelabs.com/radium/ [1] https:…
Using inline style for everything like Radium does is going to be much more expensive than using stylesheets.
That was my initial though, in CSS you can reuse classes and other code, right? But in react components can also be reused and/or extended. I would say, that using CSS makes managing big project way more expensive than using React/something similar. It's not intuitive, but you don't have to believe me, Facebook and Instagram have pretty big codebases and react with inline styles is their solution - while it's not an argument per se, it's a hint that this approach may work.
Re: React JS Best Practices
#90Earlier quoted context omitted.
Great question! Actions should be thought of as a mapping between some mechanical UI event (typing in a form, clicking on a button) and an event with some meaning in your application ("user typed a hacker news comment", "user submitted a reply to this comment with this text"). Whatever your application data store abstraction is, it should be responsible for taking that meaningful event and figuring out what to do wit…
Thanks for your explanation, that makes sense theoretically but... could you provide a code example for how this breaks out in practice?
I guess what s/he meant was having something like this in the store:
handleComment(comment) {
if (comment === '') this.dispatch('comment-error', 'empty')
else svc.send(comment)
.then(() => this.dispatch('comment-success')
.catch(err => this.dispatch('comment-error', err))
}
It does look quite complicated compared with typical error handling code. Not sure if I misunderstood something or whether this additional layer of message dispatching is worthwhile in most apps.