Everywhere in my code in order for the page to be quick using React. I suspect I'm doing something wrong, but I hate when I can't figure out why it takes 2-3 seconds for an element to show up on the page when it turns out it's because of the render.
0
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
Everywhere in my code in order for the page to be quick using React. I suspect I'm doing something wrong, but I hate when I can't figure out why it takes 2-3 seconds for an element to show up on the page when it turns out it's because of the render.
check out your shouldComponentUpdate lifecycle methods.
also make sure your mixins arent conflicting if you have them (facebook themselves are moving away from mixins).
Everywhere in my code in order for the page to be quick using React. I suspect I'm doing something wrong, but I hate when I can't figure out why it takes 2-3 seconds for an element to show up on the page when it turns out it's because of the render.
check out your shouldComponentUpdate lifecycle methods.
also make sure your mixins arent conflicting if you have them (facebook themselves are moving away from mixins).
I'm still fuzzy on what it actually does. I know that if I put return true then it will always re-render, but I can also prevent it from doing that. But it seems that if I put true it still takes forever. Is there something I'm missing?
public static string Truncate(string value, int length)
{
string res = value;
if (res != null)
{
res = value.Substring(0, Math.Min(value.Length, length));
}
return res;
}
Well now I can shorten the null-check, so it looks like this (which confused the fuck outta me):
public static string Truncate(string value, int length)
{
return value?.Substring(0, Math.Min(value.Length, length));
}
Wheeeeeeeeeeeeeeeeeee. I like the idea, but I dunno about the syntax... my eyes don't like the "?." syntax.
The syntax for it is the worst. Especially since there are languages that let you use things like ? in method names.
Yeah but C# isn't one of them and it's too late to get a really good enforcement policy like Ruby has
Just be verbose about it, it's not hard and infinitely more readable to use a few lines to check for null. Syntactic sugar is like real sugar: if used in excess, it ruins the product.
Or a ternary. Hell its basically just shortening a ternary as is.
Sounds like he was confused or deliberately foggy (in an attempt to get more $$$) about the scope of his contract. There's not really any way for us to say which one.
I mean, the meeting lasted for almost two hours (it included the full on boarding), and we went over in great detail a half dozen graphs that he was going to design and implement for us. He just came across as very "no, no you need to have this." Which, I mean, if we had some mess of a project, I could see. But I mean, it is probably not perfect, but it's certainly not an issue in any way shape or form. http://imgur.com/a/q6OqW
His attitude just got very disdainful when he found out I wasn't using a visual framework.
Bootstrap makes the layout dead simple, especially for your mockup image there.
He was probably upset because you were asking him to reinvent the wheel at his own cost.
But if his only job was to design and implement graphs he should never have been touching the layout.
Maybe.
I'm guessing his job was to make the pages that hosted those graphs, too.
And to match them up to a website.
And a vague allusion to "make it match the colors"
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Sounds like he was confused or deliberately foggy (in an attempt to get more $$$) about the scope of his contract. There's not really any way for us to say which one.
I mean, the meeting lasted for almost two hours (it included the full on boarding), and we went over in great detail a half dozen graphs that he was going to design and implement for us. He just came across as very "no, no you need to have this." Which, I mean, if we had some mess of a project, I could see. But I mean, it is probably not perfect, but it's certainly not an issue in any way shape or form. http://imgur.com/a/q6OqW
His attitude just got very disdainful when he found out I wasn't using a visual framework.
Bootstrap makes the layout dead simple, especially for your mockup image there.
He was probably upset because you were asking him to reinvent the wheel at his own cost.
But if his only job was to design and implement graphs he should never have been touching the layout.
Maybe.
I'm guessing his job was to make the pages that hosted those graphs, too.
And to match them up to a website.
And a vague allusion to "make it match the colors"
Maybe, but that's an assumption. That's why my original response basically said that the scope was probably unclear and there's no way that we can definitively answer Mvrck's confusion, because we weren't in the room with them.
Everywhere in my code in order for the page to be quick using React. I suspect I'm doing something wrong, but I hate when I can't figure out why it takes 2-3 seconds for an element to show up on the page when it turns out it's because of the render.
check out your shouldComponentUpdate lifecycle methods.
also make sure your mixins arent conflicting if you have them (facebook themselves are moving away from mixins).
I'm still fuzzy on what it actually does. I know that if I put return true then it will always re-render, but I can also prevent it from doing that. But it seems that if I put true it still takes forever. Is there something I'm missing?
shouldComponentUpdate determines just that. if a component should update.
you generally want a component to only update when absolutely necessary. setting it to always return true is not what you want.
im willing to bet somehow a higher component in your layout is being updated when maybe it doesnt have to. when a component updates, it will go down and update all child components if it needs to. you can stop child components from updating by returning false in certain conditions.
ANYWAYS, i know i said to avoid mixins, BUT you could try to use facebooks own PureRenderMixin on all your components and see if that speeds things up. just be sure to get rid of all the other shouldComponentUpdates so that that mixin doesnt conflict.
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
edited August 2015
basically i think that for whatever reason you might have a state or prop change flowing down through your entire app, and thus react is redrawing everything instead of the minimal amount.
and yeah if you are doing forceUpdate, then it is very likely that is the case
Well without the forceUpdate then it takes a few seconds to respond to button clicks (so if they click a delete button on a component then it would take a few seconds to disappear). But, like I said, I suspect that our app is probably setup differently than what most React apps are.
When the component mounts then we hit an API endpoint to grab some data and then populate the state with that, when the data comes through then we do a forceUpdate and render the components. Then the user can remove/add components on the fly so it's really difficult to keep the shouldComponentUpdate working properly.
If I had the time I'd love to go back and rewrite all of these components again for the tenth time. But we go live in 3 weeks and we have ZERO unit tests so if I change anything then we have to manually run through everything to make sure it doesn't break anything.
Me reading something registering to be a factory: Okay, you've called a function... that takes ... an empty... set of parameters I think.... and then an array of... arbitrary types some of which are themselves functions which also take empty parameters and there's another array of... *weep*
Edit: At least the indenting makes this obvious! Yaaaay for indents!
Edit2: Is this level of nesting a common style for Javascript/Web dev? Is this why I find lambdas in lambdas in lambdas in other places? =P
Edit3: I mean, I get that it's ended up creating a whole anonymous type in the function call when registering to be a factory, but man. Maybe I would be more comfortable with TypeScript.
The problem with javascript is that it doesn't take objects very seriously, so there are a gazillion different ways to make it more OOP-like, and they are all different in varying ways and none of them quite work like objects in C++ et al, they just look like they do in ways that will confuse you to no end until you work out what's really going on. In particular, the way "this" doesn't mean the same "this" that "this" means in other languages can be a super big pain.
I'll say this for Javascript - it's a very flexible language. Perhaps too flexible for my personal taste, although I can certainly appreciate how it can be made to do almost anything...
On the bright side, I've got my front end view requesting data via AngularJS, and now... I just have to wire it up to the EF back end.
A year ago, I never thought I'd ever be saying anything resembling that sentence.
Edit: Web dev skill level: Code monkey see, code monkey does. Still have much to learn. Cannot design at this stage, merely implement.
The problem with javascript is that it doesn't take objects very seriously, so there are a gazillion different ways to make it more OOP-like, and they are all different in varying ways and none of them quite work like objects in C++ et al, they just look like they do in ways that will confuse you to no end until you work out what's really going on. In particular, the way "this" doesn't mean the same "this" that "this" means in other languages can be a super big pain.
It's not that Javascript doesn't take its objects seriously. It's that Javascript's prototype-based object model is fundamentally different from the traditional class-based object models found in Java or C++. It's very beautiful in its simplicity although I agree that the syntax of the language is deceptively similar to it's class-based cousins so that it's easy to get the two paradigms confused.
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
The problem with javascript is that it doesn't take objects very seriously, so there are a gazillion different ways to make it more OOP-like, and they are all different in varying ways and none of them quite work like objects in C++ et al, they just look like they do in ways that will confuse you to no end until you work out what's really going on. In particular, the way "this" doesn't mean the same "this" that "this" means in other languages can be a super big pain.
It's not that Javascript doesn't take its objects seriously. It's that Javascript's prototype-based object model is fundamentally different from the traditional class-based object models found in Java or C++. It's very beautiful in its simplicity although I agree that the syntax of the language is deceptively similar to it's class-based cousins so that it's easy to get the two paradigms confused.
Yeah, that's a better way to phrase things. The first (decent-sized) javascript project we worked on we used pure thing.prototype.doStuff() everywhere because it made it more obvious what was and what wasn't going on; there are many more ingenious approaches, but none of us had the instinct for javascript enough to want to do anything that wasn't really really easy to understand, and very unlikely to do anything unexpected.
We have arrived(ish) on a stack for one of our web apps. We need a mostly static and accessible front-end website for clients and purchasers, and a richer back-end application for admin/CSRs to manage accounts and authorizations and such. Some reports and visualizations for that latter one.
So, we have moved away from Angular which my dev is very familiar with, since it is more suited to internal apps where you have target browsers and can make a lot more assumptions. We need that, yes, but I'd like to have these two web apps sharing a stack as much as possible to aid the devs and also because they will both need to communicate with some kind of black-box server behind them. All the domain data has to come from the black-box(es).
Looking at doing React now, since isomorphic means I expect to be able to have components that could be reusable but mostly to have things consistent working on both apps, but having the front-end do server-side rendering for the page load and maybe having some client-side to do push rendering of a specific set of components (ticker, dashboard panels, etc.). The back-end app will be mostly client-side rendered and much more dynamic / one-page style.
Choice of React here good, y/n?
Trying to sort out the data that best suits this idea now. It will be [Client Browser] <=> [Web App VM] <=> [Data API VM (wrapping the database)] with the Web App VM swapping out per above.
Lot of stuff to read up on lately, with Relay and Falcor and such.
WHAT DO?!?
(Thanks.)
edit: also probably important, the "Data API VM" has to serve data not just by the session user but also by the Web App that is requesting, eg. the front-end app has less visibility into the data so that even a full compromise of the front-end Web App VM can't access certain data.
Infidel on
0
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
edited August 2015
isomorphic is a definite advantage.
that being said, it is not as easy as using React.renderToString(). there is a lot more that goes on with it, especially if you have to fetch data server side.
if going with react, i would strongly suggest looking at flux to handle app state and data. ideally a framework like alt, fluxible or redux that has async isomorphic solutions already. trust me, you dont wanna be handling state purely through react. ideally you would have "stateless" components that just recieve new props from flux stores that hold state. i think this might be one of the issues @urahonky is having, but thats just speculation on my part.
react is reusable by nature, so its good for larger projects. i actually wouldnt suggest a person use react if doig a small website because the amount of initial work and boilerplate needed isnt immediately benefical nor speeds up dev.
its when you get complex UIs and common patterns that the power of Reacts reusablity really shines.
... All the domain data has to come from the black-box(es).
Looking at doing React now, since isomorphic means I expect to be able to have components that could be reusable but mostly to have things consistent working on both apps, but having the front-end do server-side rendering for the page load and maybe having some client-side to do push rendering of a specific set of components (ticker, dashboard panels, etc.). The back-end app will be mostly client-side rendered and much more dynamic / one-page style.
Choice of React here good, y/n?
It seems to be, but are you targeting mobile in any way?
Other things to keep in mind: If you are all going to be learning the approach on the job, really make sure you can not rely on the technology you already have an expert it (ng) before switching to React. While I don't think that the approach is difficult in itself, experience says the first time always has unexpected bumps and if you have to deliver soon, it may not be worth it.
Anecdotal: I'm aware of at least one case where an NG dev quit after a switch to React.
Random: I genuinely believe that Reagent is the most accessible way there is to write/design React applications. http://reagent-project.github.io/ (doesn't mean it's the best....)
Trying to sort out the data that best suits this idea now. It will be [Client Browser] <=> [Web App VM] <=> [Data API VM (wrapping the database)] with the Web App VM swapping out per above.
Lot of stuff to read up on lately, with Relay and Falcor and such.
WHAT DO?!?
You don't need to go that way, Relay/Falcor are nice, but you are perfectly able to design a solid React application with a data flow you are more used to (standard backend split, even if you do rendering there).
edit: also probably important, the "Data API VM" has to serve data not just by the session user but also by the Web App that is requesting, eg. the front-end app has less visibility into the data so that even a full compromise of the front-end Web App VM can't access certain data.
ACL on frontend level(for display purposes) and enforcement on the backend (in case somebody tries to be smart) is relatively easy with https://en.wikipedia.org/wiki/JSON_Web_Token carrying permissions as part of payload or a similar strategy. Ask concretes if you run into a design roadblock.
So, graduated, and managed to land a job. The pay is OK (for my country at least), and includes insurance and stuff.
Is distance work of basically using Cordova (the free PhoneGap) to make a company app from a webpage, the whole thing is selling corporate solutions so is not a social media crapshoot, thank God. Office hours of being connected to the company chatroom and doing stuff on Netbeans (I like it), while using the company repository
And it uses Ionic and Ionic-Material to give it that sleek phone app appereance while being a regular AngularJS webpage. Neat.
TryCatcher on
+3
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
ive messed with ionic. prolly the best hybrid app framework out there.
... All the domain data has to come from the black-box(es).
Looking at doing React now, since isomorphic means I expect to be able to have components that could be reusable but mostly to have things consistent working on both apps, but having the front-end do server-side rendering for the page load and maybe having some client-side to do push rendering of a specific set of components (ticker, dashboard panels, etc.). The back-end app will be mostly client-side rendered and much more dynamic / one-page style.
Choice of React here good, y/n?
It seems to be, but are you targeting mobile in any way?
Other things to keep in mind: If you are all going to be learning the approach on the job, really make sure you can not rely on the technology you already have an expert it (ng) before switching to React. While I don't think that the approach is difficult in itself, experience says the first time always has unexpected bumps and if you have to deliver soon, it may not be worth it.
Anecdotal: I'm aware of at least one case where an NG dev quit after a switch to React.
Random: I genuinely believe that Reagent is the most accessible way there is to write/design React applications. http://reagent-project.github.io/ (doesn't mean it's the best....)
Trying to sort out the data that best suits this idea now. It will be [Client Browser] <=> [Web App VM] <=> [Data API VM (wrapping the database)] with the Web App VM swapping out per above.
Lot of stuff to read up on lately, with Relay and Falcor and such.
WHAT DO?!?
You don't need to go that way, Relay/Falcor are nice, but you are perfectly able to design a solid React application with a data flow you are more used to (standard backend split, even if you do rendering there).
edit: also probably important, the "Data API VM" has to serve data not just by the session user but also by the Web App that is requesting, eg. the front-end app has less visibility into the data so that even a full compromise of the front-end Web App VM can't access certain data.
ACL on frontend level(for display purposes) and enforcement on the backend (in case somebody tries to be smart) is relatively easy with https://en.wikipedia.org/wiki/JSON_Web_Token carrying permissions as part of payload or a similar strategy. Ask concretes if you run into a design roadblock.
+1 on the JSON Web Token front.
ya there are other things than flux even.
backbone was actually a prefered data handler with react for a long time. could also check out firebase i suppose.
id also agree to steer away from relay/graphql/falcor for now. all signs point to them being awesome, but they are still in tech-preview.
The problem with javascript is that it doesn't take objects very seriously, so there are a gazillion different ways to make it more OOP-like, and they are all different in varying ways and none of them quite work like objects in C++ et al, they just look like they do in ways that will confuse you to no end until you work out what's really going on. In particular, the way "this" doesn't mean the same "this" that "this" means in other languages can be a super big pain.
It's not that Javascript doesn't take its objects seriously. It's that Javascript's prototype-based object model is fundamentally different from the traditional class-based object models found in Java or C++. It's very beautiful in its simplicity although I agree that the syntax of the language is deceptively similar to it's class-based cousins so that it's easy to get the two paradigms confused.
One thing which I think people don't necessarily keep in mind is the history of JavaScript. While the history doesn't mean that it's great, it does explain a lot of the terrible bits and make some of it all the more impressive. To paraphrase part of a talk I saw by either Brendan Eich or Douglas Crockford (I think Crockford), JavaScript was designed from day one to only be a few lines of code here and there to make your gif move across the screen or whatever. A really, really, really big js program was intended to be 100 lines. That intention and assumption is why there are underlying architectural things which make these giant full on apps we do with it today get so messy so easily. Basically, we're using the wrong tool for the job every day (because there's not currently a correct tool for the job) and then wondering why it's painful.
The problem with JavaScript is that it's JavaScript.
shit like type coercion (This shit is almost as bad as php's true/false/filenotfound and 0/null/exception)
global variables (did you misspell poopyButt as poopy ? Well now poopy is a global variable, good luck!)
shitty scope correctness
There's a few dozen others.
Plus it has a few gotchas. Semicolon placement is awkward and not required, sometimes. Sometimes it is. The language tries to figure it out. That's just stupid.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
I would like to mention that even dealing with JavaScript is still better than dealing with the slow, frustrating, crammed into Java, with resource hog IDEs crazy train that is native Android development.
Yeah I'll give you that. JS is way better than Java.
Loads.
I still don't know what this proclivity is to taking java programs and porting them to a website and using JS though, lots of people are doing it.
I always hear scaling, but I can't really get behind that idea. You're taking local apps, which are essentially distributed computing and comparing them to centrally hosted apps, that often use one of the worst concurrency models.
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
The problem with JavaScript is that it's JavaScript.
shit like type coercion (This shit is almost as bad as php's true/false/filenotfound and 0/null/exception)
global variables (did you misspell poopyButt as poopy ? Well now poopy is a global variable, good luck!)
shitty scope correctness
There's a few dozen others.
Plus it has a few gotchas. Semicolon placement is awkward and not required, sometimes. Sometimes it is. The language tries to figure it out. That's just stupid.
Yes, and that all stems from that it was intended to be a toy that you write 10 lines of, not thousands of lines across 50 different files. It doesn't make it any better for what we're doing with it, but explains it. It's about like being surprised that a Fisher Price drill in a kids toy toolset falls apart when trying to build a house with it because the motor isn't strong enough and the drill bits break and it doesn't quite fit your adult hands and faulting the tool for that. It doesn't have those things because it was never meant to be used in a situation where those things would matter. We just ended up doing so anyway and have painted ourselves into a corner where we now have no choice but to keep on using the wrong tool.
Not concerned very much about the React side of getting ramped up, I wanna figure out the stack asap though because the permanent dev hasn't been hired yet and I need to know what to look for there.
Have been poking around at docs all last night and keep slicing things off until I reach something I like.
Posts
Everywhere in my code in order for the page to be quick using React. I suspect I'm doing something wrong, but I hate when I can't figure out why it takes 2-3 seconds for an element to show up on the page when it turns out it's because of the render.
check out your shouldComponentUpdate lifecycle methods.
also make sure your mixins arent conflicting if you have them (facebook themselves are moving away from mixins).
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
I'm still fuzzy on what it actually does. I know that if I put return true then it will always re-render, but I can also prevent it from doing that. But it seems that if I put true it still takes forever. Is there something I'm missing?
Or a ternary. Hell its basically just shortening a ternary as is.
3DS: 0473-8507-2652
Switch: SW-5185-4991-5118
PSN: AbEntropy
Maybe.
I'm guessing his job was to make the pages that hosted those graphs, too.
And to match them up to a website.
And a vague allusion to "make it match the colors"
This sounds awesome!
Maybe, but that's an assumption. That's why my original response basically said that the scope was probably unclear and there's no way that we can definitively answer Mvrck's confusion, because we weren't in the room with them.
shouldComponentUpdate determines just that. if a component should update.
you generally want a component to only update when absolutely necessary. setting it to always return true is not what you want.
im willing to bet somehow a higher component in your layout is being updated when maybe it doesnt have to. when a component updates, it will go down and update all child components if it needs to. you can stop child components from updating by returning false in certain conditions.
ANYWAYS, i know i said to avoid mixins, BUT you could try to use facebooks own PureRenderMixin on all your components and see if that speeds things up. just be sure to get rid of all the other shouldComponentUpdates so that that mixin doesnt conflict.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
and yeah if you are doing forceUpdate, then it is very likely that is the case
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
When the component mounts then we hit an API endpoint to grab some data and then populate the state with that, when the data comes through then we do a forceUpdate and render the components. Then the user can remove/add components on the fly so it's really difficult to keep the shouldComponentUpdate working properly.
Me reading something registering to be a factory: Okay, you've called a function... that takes ... an empty... set of parameters I think.... and then an array of... arbitrary types some of which are themselves functions which also take empty parameters and there's another array of... *weep*
Edit: At least the indenting makes this obvious! Yaaaay for indents!
Edit2: Is this level of nesting a common style for Javascript/Web dev? Is this why I find lambdas in lambdas in lambdas in other places? =P
Edit3: I mean, I get that it's ended up creating a whole anonymous type in the function call when registering to be a factory, but man. Maybe I would be more comfortable with TypeScript.
I'll say this for Javascript - it's a very flexible language. Perhaps too flexible for my personal taste, although I can certainly appreciate how it can be made to do almost anything...
On the bright side, I've got my front end view requesting data via AngularJS, and now... I just have to wire it up to the EF back end.
A year ago, I never thought I'd ever be saying anything resembling that sentence.
Edit: Web dev skill level: Code monkey see, code monkey does. Still have much to learn. Cannot design at this stage, merely implement.
My career is like a bishop.
It goes diagonally.
It's not that Javascript doesn't take its objects seriously. It's that Javascript's prototype-based object model is fundamentally different from the traditional class-based object models found in Java or C++. It's very beautiful in its simplicity although I agree that the syntax of the language is deceptively similar to it's class-based cousins so that it's easy to get the two paradigms confused.
What device will this website be embedded into?
... touche, sir. Touche! =P
there is almost nothing it cant do. you can literally bend it to your will.
but that also means you can end up with very very bad habits that "work"
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
Yeah, that's a better way to phrase things. The first (decent-sized) javascript project we worked on we used pure thing.prototype.doStuff() everywhere because it made it more obvious what was and what wasn't going on; there are many more ingenious approaches, but none of us had the instinct for javascript enough to want to do anything that wasn't really really easy to understand, and very unlikely to do anything unexpected.
So, we have moved away from Angular which my dev is very familiar with, since it is more suited to internal apps where you have target browsers and can make a lot more assumptions. We need that, yes, but I'd like to have these two web apps sharing a stack as much as possible to aid the devs and also because they will both need to communicate with some kind of black-box server behind them. All the domain data has to come from the black-box(es).
Looking at doing React now, since isomorphic means I expect to be able to have components that could be reusable but mostly to have things consistent working on both apps, but having the front-end do server-side rendering for the page load and maybe having some client-side to do push rendering of a specific set of components (ticker, dashboard panels, etc.). The back-end app will be mostly client-side rendered and much more dynamic / one-page style.
Choice of React here good, y/n?
Trying to sort out the data that best suits this idea now. It will be [Client Browser] <=> [Web App VM] <=> [Data API VM (wrapping the database)] with the Web App VM swapping out per above.
Lot of stuff to read up on lately, with Relay and Falcor and such.
WHAT DO?!?
(Thanks.)
edit: also probably important, the "Data API VM" has to serve data not just by the session user but also by the Web App that is requesting, eg. the front-end app has less visibility into the data so that even a full compromise of the front-end Web App VM can't access certain data.
that being said, it is not as easy as using React.renderToString(). there is a lot more that goes on with it, especially if you have to fetch data server side.
if going with react, i would strongly suggest looking at flux to handle app state and data. ideally a framework like alt, fluxible or redux that has async isomorphic solutions already. trust me, you dont wanna be handling state purely through react. ideally you would have "stateless" components that just recieve new props from flux stores that hold state. i think this might be one of the issues @urahonky is having, but thats just speculation on my part.
react is reusable by nature, so its good for larger projects. i actually wouldnt suggest a person use react if doig a small website because the amount of initial work and boilerplate needed isnt immediately benefical nor speeds up dev.
its when you get complex UIs and common patterns that the power of Reacts reusablity really shines.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
It will be fun the first time he causes a segfault!
It seems to be, but are you targeting mobile in any way?
Other things to keep in mind: If you are all going to be learning the approach on the job, really make sure you can not rely on the technology you already have an expert it (ng) before switching to React. While I don't think that the approach is difficult in itself, experience says the first time always has unexpected bumps and if you have to deliver soon, it may not be worth it.
Anecdotal: I'm aware of at least one case where an NG dev quit after a switch to React.
Random: I genuinely believe that Reagent is the most accessible way there is to write/design React applications. http://reagent-project.github.io/ (doesn't mean it's the best....)
You don't need to go that way, Relay/Falcor are nice, but you are perfectly able to design a solid React application with a data flow you are more used to (standard backend split, even if you do rendering there).
ACL on frontend level(for display purposes) and enforcement on the backend (in case somebody tries to be smart) is relatively easy with https://en.wikipedia.org/wiki/JSON_Web_Token carrying permissions as part of payload or a similar strategy. Ask concretes if you run into a design roadblock.
So, graduated, and managed to land a job. The pay is OK (for my country at least), and includes insurance and stuff.
Is distance work of basically using Cordova (the free PhoneGap) to make a company app from a webpage, the whole thing is selling corporate solutions so is not a social media crapshoot, thank God. Office hours of being connected to the company chatroom and doing stuff on Netbeans (I like it), while using the company repository
And it uses Ionic and Ionic-Material to give it that sleek phone app appereance while being a regular AngularJS webpage. Neat.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
+1 on the JSON Web Token front.
ya there are other things than flux even.
backbone was actually a prefered data handler with react for a long time. could also check out firebase i suppose.
id also agree to steer away from relay/graphql/falcor for now. all signs point to them being awesome, but they are still in tech-preview.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
shit like type coercion (This shit is almost as bad as php's true/false/filenotfound and 0/null/exception)
global variables (did you misspell poopyButt as poopy ? Well now poopy is a global variable, good luck!)
shitty scope correctness
There's a few dozen others.
Plus it has a few gotchas. Semicolon placement is awkward and not required, sometimes. Sometimes it is. The language tries to figure it out. That's just stupid.
Loads.
I still don't know what this proclivity is to taking java programs and porting them to a website and using JS though, lots of people are doing it.
I always hear scaling, but I can't really get behind that idea. You're taking local apps, which are essentially distributed computing and comparing them to centrally hosted apps, that often use one of the worst concurrency models.
Yes, and that all stems from that it was intended to be a toy that you write 10 lines of, not thousands of lines across 50 different files. It doesn't make it any better for what we're doing with it, but explains it. It's about like being surprised that a Fisher Price drill in a kids toy toolset falls apart when trying to build a house with it because the motor isn't strong enough and the drill bits break and it doesn't quite fit your adult hands and faulting the tool for that. It doesn't have those things because it was never meant to be used in a situation where those things would matter. We just ended up doing so anyway and have painted ourselves into a corner where we now have no choice but to keep on using the wrong tool.
I would rather have seen something like LUA with node instead of JavaScript.
Just... anything but JavaScript come the fuck on.
Not concerned very much about the React side of getting ramped up, I wanna figure out the stack asap though because the permanent dev hasn't been hired yet and I need to know what to look for there.
Have been poking around at docs all last night and keep slicing things off until I reach something I like.
It's a reinforcing cycle. The browsers only support js so everybody uses js which ensures the browsers will only support js
In Node's case... there was absolutely no reason to pick JavaScript, it's not really acting on the browser.
it's because people wanted a server-side environment where they could use the same code they use on the front-end
which meant they had to use js