Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Maluco Marinero
Jan 18, 2001

Damn that's a
fine elephant.
The shadow Dom is one of the best ideas for web application rendering in quite awhile, especially in terms of performance. I'm not surprised everyone is copying it, and given React is just view layer, angular et al are more all-encompassing that's not such a bad thing. The main thing it gets you thinking more about is how state gets passed through your application.

Adbot
ADBOT LOVES YOU

Huzanko
Aug 4, 2015

by FactsAreUseless

Maluco Marinero posted:

The shadow Dom is one of the best ideas for web application rendering in quite awhile, especially in terms of performance. I'm not surprised everyone is copying it, and given React is just view layer, angular et al are more all-encompassing that's not such a bad thing. The main thing it gets you thinking more about is how state gets passed through your application.

I don't mean to say I disagree with their copying of React. Quite the opposite. I'm just wondering what the incentive is to stick with Angular if it's going to be just like React, but I probably need to see more complex Angular 2 applications that leverage more of Angular's featureset before I make that kind of determination.

Skandranon
Sep 6, 2008
fucking stupid, dont listen to me

Noam Chomsky posted:

I don't mean to say I disagree with their copying of React. Quite the opposite. I'm just wondering what the incentive is to stick with Angular if it's going to be just like React, but I probably need to see more complex Angular 2 applications that leverage more of Angular's featureset before I make that kind of determination.

I prefer Angular in that it is the entire MVC framework, React is just the view component. Angular 2.0 with shadowdom and TypeScript integration from the ground up sounds like there will be no need for React, in my world anyways. But, it's not done yet, so we'll see.

Huzanko
Aug 4, 2015

by FactsAreUseless

Skandranon posted:

I prefer Angular in that it is the entire MVC framework, React is just the view component. Angular 2.0 with shadowdom and TypeScript integration from the ground up sounds like there will be no need for React, in my world anyways. But, it's not done yet, so we'll see.

Agreed. I think my initial impression is based on the examples being so simplistic. I'm used to working on fairly big applications that leverage a lot of Angular and lots of third-party modules. So, I think I'll start down the path of building out my boilerplate in Angular 2 - it'll be a good opportunity to learn TypeScript as well.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Skandranon posted:

I prefer Angular in that it is the entire MVC framework, React is just the view component. Angular 2.0 with shadowdom and TypeScript integration from the ground up sounds like there will be no need for React, in my world anyways. But, it's not done yet, so we'll see.

Unless you'd like to use React now, in which case you can just learn / use React. The you don't have to relearn anything or port code. But that's just me, obviously, as I really disliked just about everything about Angular, but different strokes and all that.

Uziel
Jun 28, 2004

Ask me about losing 200lbs, and becoming the Viking God of W&W.
If react is just the view, what is generally used for the model and controller? We are stuck in front end framework hell.

Skandranon
Sep 6, 2008
fucking stupid, dont listen to me

Lumpy posted:

Unless you'd like to use React now, in which case you can just learn / use React. The you don't have to relearn anything or port code. But that's just me, obviously, as I really disliked just about everything about Angular, but different strokes and all that.

If the goal is to use React, use it. I'm content to wait for shadowdom in Angular 2.0.

I'll agree, Angular has a lot of warts from it's early days, and there are ways of making it a lot more tolerable, especially when you throw TypeScript into the mix. I definitely could not go back to the early 1.0/1.2 days, or even doing it without TypeScript, but I somehow did at one point. Angular 2.0 is going to get rid of a lot of those warts, and, providing there is some good documentation on best practices, should be a much better affair all around this time.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

Uziel posted:

If react is just the view, what is generally used for the model and controller? We are stuck in front end framework hell.

It's complicated.

As it says (used to?) on the React site, many people use React as the "V" in MVC. But there's more and more people bending the whole thing away from a traditional MVC type of thing by using Flux and Flux-inspired sorts of things like redux.

Anyway, people use React with Angular (mostly as a replacement for directives), Ember, Backbone....umm, basically anything you can think of that does the "M" and the "C" in javascript.

edit: Found the graphics I was faintly recalling that describe Flux vs MVC: http://fluxxor.com/what-is-flux.html (fluxxor is a fairly popular implmentation of the Flux system articulated by Facebook)


(but really everyone should just use redux instead of that old and busted Flux from a few months ago)

Thermopyle fucked around with this message at 01:27 on Nov 25, 2015

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Uziel posted:

If react is just the view, what is generally used for the model and controller? We are stuck in front end framework hell.

Short answer: whatever you want!

Real answer: most react apps use the "flux" architecture (there are many implementations, or make your own!) in which the application state lives in stores (or single store in small apps or implementations like Redux). What is rendered is derived from the store only: components "just read" from it and render based on what's there.

To modify the state in the stores, one dispatches "actions" from either a single Dispatcher or something like it (again, there are many implementations) and those actions cause the store(s) that are interested in that action to update. Once a store updates, it notifies any components that are subscribed to it that it changed, and they can rerender if needed.

So in the horribly trite ToDo app example, there will be a list of "todos" in a store. When a user types in some text and clicks 'add', an "add_todo" action is dispatched. The store gets the action, adds the value in the actions payload to the list of todos it is keeping track of, and notifies it's listener, the ToDoList component, which rerender a because the data it is interested in has changed.

There are many, many implementations so what I just typed up is a very rough overview: each implementation is a bit different in how it handles things, so good news is you can find one that fits your style. Bad news is, there's a lot of them, so you have to look around and so forth. Many of us like Redux, which always keeps state in a single Store which also acts as the dispatcher. Any change to state has to flow through a "pure" function reducer, so you don't mutate your state.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Skandranon posted:

If the goal is to use React, use it. I'm content to wait for shadowdom in Angular 2.0.

I'll agree, Angular has a lot of warts from it's early days, and there are ways of making it a lot more tolerable, especially when you throw TypeScript into the mix. I definitely could not go back to the early 1.0/1.2 days, or even doing it without TypeScript, but I somehow did at one point. Angular 2.0 is going to get rid of a lot of those warts, and, providing there is some good documentation on best practices, should be a much better affair all around this time.

My experience with Angular was very early in the 1.0 days, so perhaps I'd like it much better now. I'll keep an eye on 2.0 for sure though. Some guy in this thread said I should always learn new things....

Uziel
Jun 28, 2004

Ask me about losing 200lbs, and becoming the Viking God of W&W.

Thermopyle posted:

It's complicated.

As it says (used to?) on the React site, many people use React as the "V" in MVC. But there's more and more people bending the whole thing away from a traditional MVC type of thing by using Flux and Flux-inspired sorts of things like redux.

Anyway, people use React with Angular (mostly as a replacement for directives), Ember, Backbone....umm, basically anything you can think of that does the "M" and the "C" in javascript.

edit: Found the graphics I was faintly recalling that describe Flux vs MVC: http://fluxxor.com/what-is-flux.html (fluxxor is a fairly popular implmentation of the Flux system articulated by Facebook)


(but really everyone should just use redux instead of that old and busted Flux from a few months ago)

Lumpy posted:

Short answer: whatever you want!

Real answer: most react apps use the "flux" architecture (there are many implementations, or make your own!) in which the application state lives in stores (or single store in small apps or implementations like Redux). What is rendered is derived from the store only: components "just read" from it and render based on what's there.

To modify the state in the stores, one dispatches "actions" from either a single Dispatcher or something like it (again, there are many implementations) and those actions cause the store(s) that are interested in that action to update. Once a store updates, it notifies any components that are subscribed to it that it changed, and they can rerender if needed.

So in the horribly trite ToDo app example, there will be a list of "todos" in a store. When a user types in some text and clicks 'add', an "add_todo" action is dispatched. The store gets the action, adds the value in the actions payload to the list of todos it is keeping track of, and notifies it's listener, the ToDoList component, which rerender a because the data it is interested in has changed.

There are many, many implementations so what I just typed up is a very rough overview: each implementation is a bit different in how it handles things, so good news is you can find one that fits your style. Bad news is, there's a lot of them, so you have to look around and so forth. Many of us like Redux, which always keeps state in a single Store which also acts as the dispatcher. Any change to state has to flow through a "pure" function reducer, so you don't mutate your state.

Thanks, these are helpful. It sounds like I'm between Angular 2 with TypeScript, and React with a Flux implementation. No one uses Flux with traditional MVC though?
Does anyone know if there is scheduler written for both Angular and/or React that is as robust as extjs's calendar? 50% of our app that we are converting is built around the calendar: http://examples.ext.net/#/Calendar/Overview/Basic/

Skandranon
Sep 6, 2008
fucking stupid, dont listen to me

Uziel posted:

Thanks, these are helpful. It sounds like I'm between Angular 2 with TypeScript, and React with a Flux implementation. No one uses Flux with traditional MVC though?
Does anyone know if there is scheduler written for both Angular and/or React that is as robust as extjs's calendar? 50% of our app that we are converting is built around the calendar: http://examples.ext.net/#/Calendar/Overview/Basic/

Though I have no experience at all with your calendar in question, there's no reason you can't write an Angular wrapper around it, which should be a lot less effort than converting to some different calendar widget if half of your entire application is based on it.

Huzanko
Aug 4, 2015

by FactsAreUseless

Uziel posted:

Thanks, these are helpful. It sounds like I'm between Angular 2 with TypeScript, and React with a Flux implementation. No one uses Flux with traditional MVC though?
Does anyone know if there is scheduler written for both Angular and/or React that is as robust as extjs's calendar? 50% of our app that we are converting is built around the calendar: http://examples.ext.net/#/Calendar/Overview/Basic/

Flux is an alternative to MVC.

As for calendars for Angular, there's this: https://angular-ui.github.io/ui-calendar/

Huzanko
Aug 4, 2015

by FactsAreUseless

Skandranon posted:

Though I have no experience at all with your calendar in question, there's no reason you can't write an Angular wrapper around it, which should be a lot less effort than converting to some different calendar widget if half of your entire application is based on it.

Also this.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Uziel posted:

Thanks, these are helpful. It sounds like I'm between Angular 2 with TypeScript, and React with a Flux implementation. No one uses Flux with traditional MVC though?
Does anyone know if there is scheduler written for both Angular and/or React that is as robust as extjs's calendar? 50% of our app that we are converting is built around the calendar: http://examples.ext.net/#/Calendar/Overview/Basic/

Make that a child of a React component and you're done with that part. No reason you can't use both.

Ochowie
Nov 9, 2007

What's the best IDE/Text editor for developing React? I've found WebStorm and Sublime struggle with JSX indentation. How is Facebook's Nuclide?

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Ochowie posted:

What's the best IDE/Text editor for developing React? I've found WebStorm and Sublime struggle with JSX indentation. How is Facebook's Nuclide?

I use VIM and it handles it fine. But unless you already know VIM, it might not be "the best".

Skandranon
Sep 6, 2008
fucking stupid, dont listen to me

Ochowie posted:

What's the best IDE/Text editor for developing React? I've found WebStorm and Sublime struggle with JSX indentation. How is Facebook's Nuclide?

VSCode (supposedly, not tried it) support for both JSX and TSX (TypeScript).

Edit: What I meant by "not tried it", is I've not tried the JSX part. I'm currently using VSCode for all my HTML/CSS/TypeScript development and love it.

Skandranon fucked around with this message at 06:00 on Nov 30, 2015

Ochowie
Nov 9, 2007

Lumpy posted:

I use VIM and it handles it fine. But unless you already know VIM, it might not be "the best".

I've tried with VIM but it's a bit of a pain to set it up to handle some of the JSX elements.


Skandranon posted:

VSCode (supposedly, not tried it) support for both JSX and TSX (TypeScript).

I'll give VSCode a try.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

FWIW, I do tons of JSX in Webstorm and only have a few minor complaints about its JSX formatting...

Ochowie
Nov 9, 2007

Thermopyle posted:

FWIW, I do tons of JSX in Webstorm and only have a few minor complaints about its JSX formatting...

WebStorm is probably the closest I've used but there are a few things that annoy me about it. For one, it defaults to quotes for tag attributes instead of curly braces. Also, sometimes the elements don't line up. I think it's that I'm still not that used to or a fan of JSX syntax.

Chenghiz
Feb 14, 2007

WHITE WHALE
HOLY GRAIL
I do most everything in Atom these days. VS Code is nice in general but it doesn't really do autocorrect or intellisense or anything for JSX beyond just highlighting syntax.

NovemberMike
Dec 28, 2008

Noam Chomsky posted:

Flux is an alternative to MVC.


Flux arguably is MVC. It doesn't look like a Rails style MVC pattern, but if you look at classic MVC (which has the same unidirectional data flow) there's a lot of similarities.

luchadornado
Oct 7, 2004

A boombox is not a toy!

NovemberMike posted:

Flux arguably is MVC. It doesn't look like a Rails style MVC pattern, but if you look at classic MVC (which has the same unidirectional data flow) there's a lot of similarities.

I didn't want to get all pedantic, but I was going to post essentially this earlier. For all the hullaballo that Flux solves MVC's woes (not from within this thread, mind you) a competently implemented MVC pattern with something like a repository pattern close by will look rather similar to Flux. I've got an ASP.NET MVC solution with 80+ projects and dozens of controllers, services, and datastores and I've never run into the problems outlined in that article a few posts back. You can make any pattern, even Flux, look/work like rear end if you don't put some thought into it.

I hope this isn't because the front-end devs driving this poo poo never bothered to research staples of programming like the Gang of Four and essentially re-invented useful patterns, but I've caught a few devs doing that anecdotally, so it also wouldn't surprise me for an eco-system spurred on by idioms such as "using the same language server side and client side saves time and allows you to re-use code".

I still like React and would use it for a web app any day, but some people within my organization have drank the Kool-Aid, and now they want React isomorphic and *everywhere*. Who gives a poo poo if the model adds 400kb to the HTML document size and 700ms Javascript parse time, if we already have resigned ourselves to loading tag managers, multiple analytics scripts, and a shitload of ads that all load their own analytics scripts? The page performance already sucks.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Helicity posted:

I didn't want to get all pedantic, but I was going to post essentially this earlier. For all the hullaballo that Flux solves MVC's woes (not from within this thread, mind you) a competently implemented MVC pattern with something like a repository pattern close by will look rather similar to Flux. I've got an ASP.NET MVC solution with 80+ projects and dozens of controllers, services, and datastores and I've never run into the problems outlined in that article a few posts back. You can make any pattern, even Flux, look/work like rear end if you don't put some thought into it.

I hope this isn't because the front-end devs driving this poo poo never bothered to research staples of programming like the Gang of Four and essentially re-invented useful patterns, but I've caught a few devs doing that anecdotally, so it also wouldn't surprise me for an eco-system spurred on by idioms such as "using the same language server side and client side saves time and allows you to re-use code".

I still like React and would use it for a web app any day, but some people within my organization have drank the Kool-Aid, and now they want React isomorphic and *everywhere*. Who gives a poo poo if the model adds 400kb to the HTML document size and 700ms Javascript parse time, if we already have resigned ourselves to loading tag managers, multiple analytics scripts, and a shitload of ads that all load their own analytics scripts? The page performance already sucks.

98% of a front-end developers job is to reinvent the wheel.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

Facebook engineers like Jing Chen, Peter Hunt, etc have specfically called out Flux as being an alternative to MVC, and to be honest, I think they're right and I certainly put them way ahead of your average front end developer in terms of experience and knowledge.

I mean, yeah, you can make MVC work somewhat similar to Flux, but you can stretch most systems/frameworks/patterns to work in any way you want them to.

My gut tells me that the vast majority of MVC implementations in the wild are definitely not the same thing as Flux.

Plorkyeran
Mar 22, 2007

To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed
I have found that literally everything which involves separating concerns will be described by someone as "basically just MVC" even if there aren't even three general kinds of things involved.

luchadornado
Oct 7, 2004

A boombox is not a toy!

Thermopyle posted:

My gut tells me that the vast majority of MVC implementations in the wild are definitely not the same thing as Flux.

They're different from textbook definitions, but they're rather similar in the specific issues that Flux was designed to solve. Most C# devs I've met have some idea of how to not do something completely stupid like this (from Jing's presentation on Flux):



Jing's introduction to Flux was slightly flawed because she was saying that MVC doesn't scale when her real argument (admitted later) is that bi-directional data flow is problematic, especially for situations that are state-heavy. We're having this conversation now because she pitched it as a battle between some imaginary horrible MVC implementation and her new toy. Flux is a pattern, it's a decent pattern that enforces some useful conventions, and I can see how it helps when you have hundreds of engineers working on the world's largest web app. Which most of us here probably aren't doing.

You now have those "average front end developers" that are missing education/experience tweeting about how MVC doesn't scale and how Flux solves everything. Those tweets turn into Reddit and Hacker News comment trains that reach the masses, and soon enough, it's a headache for sane developers because one or more of their peers reads the tweets/comments and now thinks React/Flux/Relay/GraphQL solves every development problem. Very much a "when all you have is a hammer, everything starts looking like a nail" mentality.

This came off to me, and apparently to others, as Facebook re-labeling and re-packaging MVC because their implementation sucked and implicitly admonishing people for choosing MVC over Flux. Stepping back from it, I understand why Flux was designed and even think it's a good thing, and it's silly to defend the honor of MVC or get bent out of shape about terminology and pattern implementation. I don't even think I'm arguing with any of you, more than I am just ranting about how stupid some of this poo poo can get. I'm seeing the hammer/nail stuff play out first-hand at the moment, and it's rather frustrating.

PlaneGuy
Mar 28, 2001

g e r m a n
e n g i n e e r i n g

Yam Slacker
As an old-school pre-dot-com dev I feel similarly. I still - probably unfairly - look down on web developers in at large because all the retarded reedit/twit/medium posts that get passed around remind me of the retarded bullshit you got from lovely php devs back in the day. "I just discovered the subscriber pattern!" I wrote a quiz about it when there was still a world trade center who gives a poo poo.

On the flipside, I love working in this space because there are smart, innovative people doing good stuff and the ease of getting something running leaves a lot of room to prototype and play. Assuming the library I picked to get up and running isn't hot garbage.

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice
A nice talk about JS frameworks: https://aerotwist.com/blog/the-cost-of-frameworks/

Spatulater bro!
Aug 19, 2003

Punch! Punch! Punch!

I've just begun learning React. I'm trying to change the styling of an element based on user input. I was able to accomplish this using refs, but when I split the app into child components, the refs no longer work. I suspect this is by design, so what is the ideal way to pass the value of a child element to a function in the parent? Or am I going about this all wrong?

http://codepen.io/caiman/pen/RrNpyX?editors=001

bartkusa
Sep 25, 2005

Air, Fire, Earth, Hope

caiman posted:

I've just begun learning React. I'm trying to change the styling of an element based on user input. I was able to accomplish this using refs, but when I split the app into child components, the refs no longer work. I suspect this is by design, so what is the ideal way to pass the value of a child element to a function in the parent? Or am I going about this all wrong?

http://codepen.io/caiman/pen/RrNpyX?editors=001

Try using the Flux pattern, using a library like Reflux or Redux.


This will split your app into four pieces.

- The Store will track the your app's data. This is basically just a pile of data sitting in memory in JS; the only special bit is that it has a callback to notify you when something in the Store has changed.

- Your React components will get the Store's contents as props. 90%+ of your React code should work off of props; rarely use state or DOM manipulation.

- When the user interacts with the React components, the event-handler should emit an Action, which is basically a message object. At this point, the React components are no longer responsible for getting work done.

- A Dispatcher will listen to all actions. Somehow, Stores will tell the Dispatcher what Actions they care about, and ask to be notified if one comes in. Dispatchers are pretty boring.

At that point, the Store may inspect the Action and mess with the data in memory, which automagically notifies the React components to read new props and rerender.

Ochowie
Nov 9, 2007

caiman posted:

I've just begun learning React. I'm trying to change the styling of an element based on user input. I was able to accomplish this using refs, but when I split the app into child components, the refs no longer work. I suspect this is by design, so what is the ideal way to pass the value of a child element to a function in the parent? Or am I going about this all wrong?

http://codepen.io/caiman/pen/RrNpyX?editors=001

bartkusa's answer is probably the correct one. However, if you don't want to go down that approach you could wrap the text elements in a form and use a form onSubmit event instead of a button onClick, addiing an event parameter to your event handler, and accessing the individual text boxes. This is pretty hacky and I would strongly suggest looking at some Flux framework. One note to point out though is that even in the Flux version the event handler would need to be pushed down to the UserInput component since it would need access to the values of the text boxes to add into the action (unless I'm missing something. I'm still pretty new to React/Flux myself).

luchadornado
Oct 7, 2004

A boombox is not a toy!

For small stuff like that I honestly wouldn't even bother with the Flux framework - just use the pattern. Bind events to a handler, have the handler figure out what event happened, and update the store appropriately (which is really just your model, aka a Javascript object). You don't need to do the annoying passing of the handler down the component chain. I'll see if I can scrounge up an easy example at work tomorrow morning.

Also, I'd go back to their tutorial and look at how children work. I honestly don't think I've ever used refs before because there isn't really a need in a lot of cases.

luchadornado fucked around with this message at 02:07 on Dec 8, 2015

Ochowie
Nov 9, 2007

Helicity posted:

For small stuff like that I honestly wouldn't even bother with the Flux framework - just use the pattern. Bind events to a handler, have the handler figure out what event happened, and update the store appropriately (which is really just your model, aka a Javascript object). You don't need to do the annoying passing of the handler down the component chain. I'll see if I can scrounge up an easy example at work tomorrow morning.

Also, I'd go back to their tutorial and look at how children work. I honestly don't think I've ever used refs before because there isn't really a need in a lot of cases.

Pretty sure refs aren't exposed up the hierarchy. I think the easiest way would be to create the event handler on the child but pass a function from the parent to the child via props that takes an argument. The event handler in the child would call the function from the parent that would update the state.

Maluco Marinero
Jan 18, 2001

Damn that's a
fine elephant.
You can get refs through a chain, ie this.refs.butt.refs.farts , but you really should avoid that whenever possible, don't use refs or give the component an API, ie this.refs.butt.getFarts()

luchadornado
Oct 7, 2004

A boombox is not a toy!

Ochowie posted:

Pretty sure refs aren't exposed up the hierarchy. I think the easiest way would be to create the event handler on the child but pass a function from the parent to the child via props that takes an argument. The event handler in the child would call the function from the parent that would update the state.

I'm saying not to use refs - instead do what you recommend with passing the root component's update function down through the props, or implement the flux pattern. Anytime you see .getDOMNode() in React there should be alarm bells going off because the whole point of React is that working with the DOM's API is horrible. Passing the root component's update function down through props is easy enough until you get more than a few layers of components and/or a few update functions, then it becomes a maintenance PITA so I'd do it once to see how it works and then happily move on.

Here's my quick and dirty "flux pattern" implementation that I mentioned the other day. It doesn't get hung up in naming things actors or dispatchers, or forcing a bunch of cruft on you. It does enable you to do one-way data flows to a central store without annoying prop chaining, which is why it's nice.

code:
var myStore = document.createElement('store');
myStore.data = {};

var updateStore = function(type, data) {
	// IE doesn't support CustomEvent constructor, ugh
	var evt = document.createEvent('CustomEvent');
	evt.initCustomEvent('update', false, false, { 'type': type, 'data': data });
	myStore.dispatchEvent(evt);
};

var AppContainer = React.createClass({
	getInitialState: function() {
		myStore.addEventListener('update', this.updateStore.bind(this));
	},
	updateStore: function(e) {
    	if (!e || !e.detail || !e.detail.type) { return; }
    	var self = this;
    	switch (e.detail.type) {
    		case 'doThing1':
    			// Do thing that changes the state
    			self.setState(self.state);
    			break;
    		case 'doThing2':
    			// Do thing that changes the state
    			self.setState(self.state);
    			break;
    	}
    }
});

Ochowie
Nov 9, 2007

Helicity posted:

I'm saying not to use refs - instead do what you recommend with passing the root component's update function down through the props, or implement the flux pattern. Anytime you see .getDOMNode() in React there should be alarm bells going off because the whole point of React is that working with the DOM's API is horrible. Passing the root component's update function down through props is easy enough until you get more than a few layers of components and/or a few update functions, then it becomes a maintenance PITA so I'd do it once to see how it works and then happily move on.

Here's my quick and dirty "flux pattern" implementation that I mentioned the other day. It doesn't get hung up in naming things actors or dispatchers, or forcing a bunch of cruft on you. It does enable you to do one-way data flows to a central store without annoying prop chaining, which is why it's nice.

Sorry, didn't mean to imply that you said that I was (wrongly) confirming your impression.

Spatulater bro!
Aug 19, 2003

Punch! Punch! Punch!

I appreciate all the helpful replies.

Another noob react question: say I have some code that allows only a logged in user to modify a file on the server via a react component (like updating a .json file, or something). What's to prevent an anonymous user from tinkering with the JS in his devtools and performing the same modifications?

Adbot
ADBOT LOVES YOU

IAmKale
Jun 7, 2007

やらないか

Fun Shoe

caiman posted:

I appreciate all the helpful replies.

Another noob react question: say I have some code that allows only a logged in user to modify a file on the server via a react component (like updating a .json file, or something). What's to prevent an anonymous user from tinkering with the JS in his devtools and performing the same modifications?
This isn't React specific, but a good rule of thumb for whenever you work on anything that interacts with a server: it's impossible to prevent anyone from tweaking any of your site's javascript once it's been downloaded to their computer. Assume that anyone who uses your website can unlock the full potential of the site.

What you need to focus on, then, is locking down your API end points to require authentication. Authentication can be handled by something as simple as a token that gets passed in with every request. This token is then used on the server side of things to verify that the user making the request has the appropriate permissions to make changes to the database. If no token is present, or if the presented token represents a user with insufficient permissions, then the request is dropped as unauthorized. Once you have that in place, it won't matter that someone has made a change to some JSON on their local machine because they won't be able to commit any of those changes to your database! :science:

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply