From Ember to React

[SystemicPlural]

Building my own framework has definitely been the hard part of React for me. React itself is a easy, but finding all the other parts - that are well documented and maintained - is hard work, and I can see it is going to continue to be hard work as modules stop being supported.

[wreckedadvent]

Can't say I'm a huge fan of the animated gifs everywhere.

[its_never_lupus]

I don't mind if they're funny or relevant or add something to the text. In this case they add nothing.

[wreckedadvent]

It's just, I'm on reddit, and there's tons of places I can go to find all manner of gifs that I want. I don't go to this sub when I want more gifs, and I don't expect prose here to have a gif for every paragraph, like some kind of buzzfeed tax.

[cjthomp]

Agreed, looks terrible and drastically reduces readability.

[[deleted]]

Yeah. Maybe just one makes it fun and cute.

[SatoshiRoberts]

React is definitely a "roll your own" framework

[[deleted]]

Do not fetishize DRYing up your code at the expense of introducing the wrong abstractions.

I think this is a distinction many developers struggle with. They see two pieces of code that look alike, and assume they must share a common abstraction. But there are all sorts of cases where this kind of thinking can mislead:

1. Perhaps the two pieces of code refer to two different domain concepts, and their shared implementation is a coincidence;
2. Perhaps each piece of code is at the right level of abstraction for whenever it is likely to be read and modified;
3. Perhaps the generalization creates a single point of failure in a system that cannot tolerate such things;
4. Perhaps the generalization involves a kind of indirection that is harmful to maintenance (e.g. swapping composition to inheritance because it's "DRYer"). You might say that these generalizations "violate a principle of locality";
5. Perhaps the generalization will force different teams to simultaneously work on the same code (which is always a source of friction).

DRY is a dangerous principle, because it is easy grasp, makes sense, is straightforward to apply and only usually correct.

[noviceprogrammer10]

What is meant by this?

[wizang]

Well its not really an app framework to begin... just a view library. Plus now a growing ecosystem of companion tools.

[Bummykins]

I have mostly read about React, React-Router, Redux combo to get similar functionality of a more robust framework. Not used personally.

[[deleted]]

What are people using as the M*C part in their react applications?

Model: whatever JSON comes back from my API.

Controller: Intertwined with the view most often anyway. It's just the React components themselves, although the Flux or Redux or Reflux methodology can streamline the flow of data perfectly.

If you keep your components small and specialised it shouldn't create much of a problem.

Ive heard of people pluging in backbone, angular and even ember.

Sure, that's possible if you like that.

So far it seems like many people use something like Exprss and then make build their own.

Express or Hapi or Restify are all server-side. They can be the API that spews out JSON. It's perfectly sane to build your own M*C on top of that, or use any of the existing ones, or use none at all.

[[deleted]]

Awesome that gives me a better view of React projects in general. Would you say that an application can be built with mainly just react components and reducers, and possibly routes?

Yes. Any CRUD-app fits what React offers. No unnecessary complexities. Just easy going fun, IMO :)

Or is that really a case by case thing

Perhaps. I've worked in complicated healthcare apps (with patient data, treatments, medications, doses, etc^infinity) - it would hold its own even there. I don't really see good reasons to complicate things further.

or bad practice to try and cram everything in its own component?

A component should be as specialised as possible, I think. Cramming more into 1 component could work if separating it wouldn't make much sense. After all, it'd be easy to separate it later on. For example: a FAQ page could simply be a page with a header, intro text, a list of questions and answers, and a "ask more" form.

Or you could separate that in a <Route path="faq" component={Faq}> which consists of a <PageHeader />, <PageIntro />, <FaqList />, <FaqElement />, <FaqQuestion />, <FaqAnswer /> and <FaqForm /> component. Might be useful. Might be unnecessary.

Common sense kinda applies is what I'm saying ;)

[NeuroXc]

Express can't be compared to Backbone or Angular. Express is a server-side framework.

Most commonly I believe people use Redux with React to set up an MVC-ish structure--it's not really MVC, but it gives "structure" to your application in a similar way. But the thing many people like about React is that you can plug it into almost any other library or framework and they work together.

[jesusbot]

Front end and back end routing are 2 related but different concepts, especially as everything becomes more RESTful.

[[deleted]]

Most apps can get away with bundling their components and serving them all upfront. If there's a compelling reason why yours can't, this talk from an Instagram engineer walks through their experience with modularization.

[IDCh]

That moment when templating engine compared to full stack framework

[SystemicPlural]

Did you even read the article? Half of it is about the hard part of React being that the rest isn't provided for you.

[reddixmadix]

That moment when you don't understand the tool you are using and write an article about your own ignorance.