Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

Anyone have any resources they could recommend as a sort of React 201 (or, "so I've made my first app, now what?"), especially in regards of how to think like a react dev? I've made a simple app but I can already see some complexity problems with taking it to the next steps. I know how I'd answer the problems in angular, but I don't know if those same ideas hold up in react.

# ? Jan 26, 2018 17:20

Adbot: ADBOT LOVES YOU

# ? Jun 10, 2024 09:41

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

dupersaurus posted:

Anyone have any resources they could recommend as a sort of React 201 (or, "so I've made my first app, now what?"), especially in regards of how to think like a react dev? I've made a simple app but I can already see some complexity problems with taking it to the next steps. I know how I'd answer the problems in angular, but I don't know if those same ideas hold up in react.

They're not written specifically for that purpose, but I think the redux docs would probably be a good thing to read even if you never use redux again.

# ? Jan 26, 2018 17:24

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Thermopyle posted:

They're not written specifically for that purpose, but I think the redux docs would probably be a good thing to read even if you never use redux again.

And watch Dan's free egghead course on Redux! https://egghead.io/courses/getting-started-with-redux

Really reinforces the "you are just rendering a state tree".

# ? Jan 26, 2018 17:50

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

Anyway I'm gonna go ahead and say there's a big boiling pentagon-shaped pot of red matter located on b10 of the Google building and they sacrifice older developers into the pot to keep @angular/core pacified lest it gain sentience and kill us all.

# ? Jan 26, 2018 19:03

streetlamp: May 7, 2007; Danny likes his party hat
He does not like his banana hat

anyone happen to use VS Code and knows how the hell can I open the find in files search/results in like a new tab or just anyway so the file explorer isn't overtaken by it?

# ? Jan 26, 2018 19:19

Knifegrab: Jul 30, 2014; Gadzooks! I'm terrified of this little child who is going to stab me with a knife. I must wrest the knife away from his control and therefore gain the upperhand.

What is the most modern and best solution to have two divs that are side by side, switch to being above/below one another depending on size of browser (responsive)

# ? Jan 26, 2018 20:07

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Knifegrab posted:

What is the most modern and best solution to have two divs that are side by side, switch to being above/below one another depending on size of browser (responsive)

CSS Grid.
It's the most modern, but really any other suggestion would depend on what is sizing the divs, and when you want them to stack.

# ? Jan 26, 2018 20:57

chime_on: Jul 27, 2001

HaB posted:

Definitely don't take an Angular 1 job in TYOOL 2018.

Ok, so can we talk about this a little again? I just had a phone interview today for a position that's generally a good fit for me in terms of the product they build, and REALLY a good fit for me in that I would have a 5 minute commute, the pay and benefits are solid, etc.

When I applied, I assumed it was Angular 2/4/5/whatever, because it said Angular, but it turns out they're using 1.6. I'm not a huge fan of Angular in any case, at least in comparison to React, but I never touched it before Angular 2. The guy said they were looking to move over to Vue, which I think I would enjoy learning, but what are the chances that I just end up squashing bugs in AngularJS until the end of time if I land this gig?

# ? Jan 26, 2018 23:59

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

The Merkinman posted:

CSS Grid.
It's the most modern, but really any other suggestion would depend on what is sizing the divs, and when you want them to stack.

Counterpoint: Flexbox. Better support, and probably easier to implement.

# ? Jan 27, 2018 00:01

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

chime_on posted:

Ok, so can we talk about this a little again? I just had a phone interview today for a position that's generally a good fit for me in terms of the product they build, and REALLY a good fit for me in that I would have a 5 minute commute, the pay and benefits are solid, etc.

When I applied, I assumed it was Angular 2/4/5/whatever, because it said Angular, but it turns out they're using 1.6. I'm not a huge fan of Angular in any case, at least in comparison to React, but I never touched it before Angular 2. The guy said they were looking to move over to Vue, which I think I would enjoy learning, but what are the chances that I just end up squashing bugs in AngularJS until the end of time if I land this gig?

My instinct says:

Are in the middle of moving to Vue == They are going to move to Vue

Looking into moving to Vue == They want to but will never have the time

But that's just me talking out my posterior.

# ? Jan 27, 2018 00:03

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

Yeah take it if they're REALLY going to move to Vue because I hear it's the hot new fad.

# ? Jan 27, 2018 00:33

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Lumpy posted:

My instinct says:

Are in the middle of moving to Vue == They are going to move to Vue

Looking into moving to Vue == They want to but will never have the time

But that's just me talking out my posterior.

Yep, moving away is a gradual process that you need to do more than look into. When I moved a project from Angular to React that was suffering from being dog slow, I figured out how to run React in the context of an Angular controller, so we could gradually strangle (https://www.martinfowler.com/bliki/StranglerApplication.html) the Angular parts out of the application.

The concrete comes from what they're planning to write in Vue while Angular is still at large. People get stuck in the 'whether it's a good idea to change technology' phase, when part of that phase should actually be 'test the new technology in some part of the existing app'. The two come together to actually turn into meaningful progress and feasibility proof.

# ? Jan 27, 2018 00:34

HaB: Jan 5, 2001; What are the odds?

Lumpy posted:

My instinct says:

Are in the middle of moving to Vue == They are going to move to Vue

Looking into moving to Vue == They want to but will never have the time

But that's just me talking out my posterior.

Agreeing with this, and would add one point:

At least Angular 1.6 has Components, so it's not a HUGE leap from there to Angular 2. But yeah...unless they have already done some PoC code, or already the move to Vue in process, be SUPER wary. You have to remember that to non-technical management, rewriting in a new framework is a non-starter, because it gains them NOTHING. "But it's working now!" is what they will say. You can sling a bunch of performance metrics at them all day, but again - "it's working now!"

I'm kind of in this situation now. Was hired to architect a move to Angular 2 for a suite of apps. Started working and quickly realized there is NO plan in place at all for doing that. One of the apps has already started using Vue. So now I am basically doing pure css / markup work that they probably could have gotten an intern to do, with a tiny bit of ng2.

# ? Jan 27, 2018 03:16

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Knifegrab posted:

What is the most modern and best solution to have two divs that are side by side, switch to being above/below one another depending on size of browser (responsive)

Table layouts with javascript that detects inner bounds of the window and restructures it.

# ? Jan 27, 2018 16:54

Professor of Cats: Mar 22, 2009

HaB posted:

Agreeing with this, and would add one point:

At least Angular 1.6 has Components, so it's not a HUGE leap from there to Angular 2. But yeah...unless they have already done some PoC code, or already the move to Vue in process, be SUPER wary. You have to remember that to non-technical management, rewriting in a new framework is a non-starter, because it gains them NOTHING. "But it's working now!" is what they will say. You can sling a bunch of performance metrics at them all day, but again - "it's working now!"

I'm kind of in this situation now. Was hired to architect a move to Angular 2 for a suite of apps. Started working and quickly realized there is NO plan in place at all for doing that. One of the apps has already started using Vue. So now I am basically doing pure css / markup work that they probably could have gotten an intern to do, with a tiny bit of ng2.

I get wanting to be on the newest but why would a business want to do this?

Please consider this scenario which is mostly what I've encountered:
1 - company has X amount of servers / apps. Note: If they spin up a new server/app for any reason, they start on the newest Angular, react, whatever.
2 - you have 4 full-stack engineers and one junior engineer dedicated to bug fixes and small tasks
3 - a feature list that is never ending (prioritized in predicted Return On Investment)
4 - a security firm to hammer your services and review your backend security once a week
5 - of those 4 engineers, the two angular experts (both in 1 and 2-5), do best practices in rendering, optimized listener counts, CSS efficiency so page renders are fast.

Repeating the question:
For an existing server/app, running older angular 1.x - why would it make any business sense at all to waste money converting that front end to use angular 5?
* You would not only waste time rewriting the same features over again, you would also have to write new e2e tests and possibly new unit tests to accommodate the new changes in UI framework, along with old fashioned user testing on top of all that. All the meanwhile you could be writing new features or even a new app that would eventually replace an old outdated app.
* Other risks include battling new framework bugs, and losing ground to competitors

A personal pet peeve of mine is unnecessary desire to "move to the latest and greatest" frontends without actually knowing why. It isn't security and if you have experienced engineers or even experienced plain developers, it shouldn't be efficiency, page loading, rendering or performance.

# ? Jan 28, 2018 01:17

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

One reason I can think of is that Angular 1.x is famously hard to use and is rife with side effects everywhere all the time. Technical debt mounts to a point where you just aren't going to get any new features on any kind of a reasonable time budget. Vue is incredibly easy to use on the other hand. You already have a working proof of concept, you can build it exactly the way it is from scratch in a matter of weeks or less.

I've seen companies struggle to escape technical debt sometimes sacrificing months or even a full year. Because their software is such a hodgepodge of technologies, cobbled together underneath the weight of an ever changing spec. It's spaghetti everywhere. That's why a company would want to switch.

Then you have a fresh start with the product more or less looking the same but it's faster, noticeably less buggy, and your developers are able to work on it.

# ? Jan 28, 2018 01:51

Professor of Cats: Mar 22, 2009

Nolgthorn posted:

One reason I can think of is that Angular 1.x is famously hard to use and is rife with side effects everywhere all the time. Technical debt mounts to a point where you just aren't going to get any new features on any kind of a reasonable time budget. Vue is incredibly easy to use on the other hand. You already have a working proof of concept, you can build it exactly the way it is from scratch in a matter of weeks or less.

I've seen companies struggle to escape technical debt sometimes sacrificing months or even a full year. Because their software is such a hodgepodge of technologies, cobbled together underneath the weight of an ever changing spec. It's spaghetti everywhere. That's why a company would want to switch.

Then you have a fresh start with the product more or less looking the same but it's faster, noticeably less buggy, and your developers are able to work on it.

I would agree that Angular 1 is difficult, but having a lot of experience in 1.x I would say it is no more difficult than angular 5. I also believe the side effects are well documented and the framework is already well vetted. (The time I spent on those side effects was before 2 was vetted and official)

Having said that, I would completely agree with you on the technical debt side; mainly when it is a large, unwieldy monolithic service you are dealing with. But I would argue that the framework isn't specially the problem there, but the entire, spaghetti monolithic architecture of it all. And I would pin that as more of a software engineering/architectural design issue and not a framework problem.

e) as a side note: I would KILL to upgrade angular 1 stuff to 5, but only if I had the time and resources.

e2) \/ \/ \/ Agreed completely on the revisions count!

Professor of Cats fucked around with this message at 02:47 on Jan 28, 2018

# ? Jan 28, 2018 02:06

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Oh, I'm more experienced with vue so naturally I'd lean toward implementing that. The monolith is a problem, but I wouldn't suggest changing it in the re-write. The goal of the re-write should be to implement all documented features as they are. Breaking the product up and further refactoring happens after the code base is minimal and manageable again. When it's manageable again, steps should also be taken to ensure the same architectural design problems don't resurface.

In my experience really good software usually goes through a couple of revisions. With the framework I'm familiar with, it can go really fast. The tools we have today are incredible in a lot of ways.

# ? Jan 28, 2018 02:42

HaB: Jan 5, 2001; What are the odds?

Professor of Cats posted:

I get wanting to be on the newest but why would a business want to do this?

Please consider this scenario which is mostly what I've encountered:
1 - company has X amount of servers / apps. Note: If they spin up a new server/app for any reason, they start on the newest Angular, react, whatever.
2 - you have 4 full-stack engineers and one junior engineer dedicated to bug fixes and small tasks
3 - a feature list that is never ending (prioritized in predicted Return On Investment)
4 - a security firm to hammer your services and review your backend security once a week
5 - of those 4 engineers, the two angular experts (both in 1 and 2-5), do best practices in rendering, optimized listener counts, CSS efficiency so page renders are fast.

Repeating the question:
For an existing server/app, running older angular 1.x - why would it make any business sense at all to waste money converting that front end to use angular 5?
* You would not only waste time rewriting the same features over again, you would also have to write new e2e tests and possibly new unit tests to accommodate the new changes in UI framework, along with old fashioned user testing on top of all that. All the meanwhile you could be writing new features or even a new app that would eventually replace an old outdated app.
* Other risks include battling new framework bugs, and losing ground to competitors

A personal pet peeve of mine is unnecessary desire to "move to the latest and greatest" frontends without actually knowing why. It isn't security and if you have experienced engineers or even experienced plain developers, it shouldn't be efficiency, page loading, rendering or performance.

None of their existing apps are on Angular 1.

The reasons I was told were:

- they had a "design firm" come in an analyze all their apps, noting what could be shared components between those apps
- the apps are all on different platforms. Everything from jsp, to vue, to Angular 2, to other older awful things I can't remember - they all look different, they all act different. So they are trying to unify their brand a bit, and of course chasing the red herring about "if all the apps are on the same platform, then any engineer can work on any app!" which as we all know rarely works that way in practice.

So the way it was pitched to me was: "all the groundwork has been done. The design firm has pinpointed all our shared components. We just need someone to come in and build out the overall layout and start building components." To me that sounds like a GREAT gig. Turns out - it's not that at all, like I said.

They just aren't ready for what they wanted me to do. Currently, there's no common auth scheme for the apps, and no good way to share data between then aside from a few specific instances.

So to directly answer your question: it's not a move from Angular 1 -> 2/4/5. It's an attempt to unify all their stuff onto one platform, since it's all over the place and some of it is ancient. Honestly if you ask me - they should have ONE app. All of the apps they have are part of ONE process, basically. But hey - I'm just a contractor.

I agree with you that it's dumb to want to move to latest and greatest just because it's the latest and greatest, but the other thing you have to consider: the longer you stay on a given framework, the smaller and smaller your pool of developer talent to recruit from gets. The last place I was at flat out refused to move off of Angular 1.5 and recruiters started telling them straight out: I have NO candidates who want to work on that. So if you are a business that uses a lot of contractors, that's something to think about. As a contractor, your bread and butter is staying on top of the latest and greatest.

That's the reason I said not to take an Angular 1 job in 2018, because you will be mostly stuck there. The frameworks of the day are React and Angular 2/4/5. Vue is starting to edge into job postings, but it has nowhere near the market share of the others, at least not where I am.

# ? Jan 28, 2018 08:15

Professor of Cats: Mar 22, 2009

HaB posted:

None of their existing apps are on Angular 1.

The reasons I was told were:

- they had a "design firm" come in an analyze all their apps, noting what could be shared components between those apps
- the apps are all on different platforms. Everything from jsp, to vue, to Angular 2, to other older awful things I can't remember - they all look different, they all act different. So they are trying to unify their brand a bit, and of course chasing the red herring about "if all the apps are on the same platform, then any engineer can work on any app!" which as we all know rarely works that way in practice.

So the way it was pitched to me was: "all the groundwork has been done. The design firm has pinpointed all our shared components. We just need someone to come in and build out the overall layout and start building components." To me that sounds like a GREAT gig. Turns out - it's not that at all, like I said.

They just aren't ready for what they wanted me to do. Currently, there's no common auth scheme for the apps, and no good way to share data between then aside from a few specific instances.

So to directly answer your question: it's not a move from Angular 1 -> 2/4/5. It's an attempt to unify all their stuff onto one platform, since it's all over the place and some of it is ancient. Honestly if you ask me - they should have ONE app. All of the apps they have are part of ONE process, basically. But hey - I'm just a contractor.

I agree with you that it's dumb to want to move to latest and greatest just because it's the latest and greatest, but the other thing you have to consider: the longer you stay on a given framework, the smaller and smaller your pool of developer talent to recruit from gets. The last place I was at flat out refused to move off of Angular 1.5 and recruiters started telling them straight out: I have NO candidates who want to work on that. So if you are a business that uses a lot of contractors, that's something to think about. As a contractor, your bread and butter is staying on top of the latest and greatest.

That's the reason I said not to take an Angular 1 job in 2018, because you will be mostly stuck there. The frameworks of the day are React and Angular 2/4/5. Vue is starting to edge into job postings, but it has nowhere near the market share of the others, at least not where I am.

Oh wow. Okay, I completely understand where you are coming from and I do entirely agree. In fact, with bigger companies, it is probably a direct sign you will be pigion holed into legacy code and will be bored out of your mind. (As well as having to do any new learning outside of your work). Great point.

# ? Jan 28, 2018 08:31

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

I think it would be correct to say if you're learning angular JS you need to make the move to Angular 2 NOW. The framework is at the beginning of its life cycle and in a year or 2 you should be able to command good money for a sr Dev position with it.

Maybe start sniffing around Vue now as well so you're in a good position 12 months from now with it.

Ape Fist fucked around with this message at 13:04 on Jan 28, 2018

# ? Jan 28, 2018 13:00

HaB: Jan 5, 2001; What are the odds?

Ape Fist posted:

I think it would be correct to say if you're learning angular JS you need to make the move to Angular 2 NOW. The framework is at the beginning of its life cycle and in a year or 2 you should be able to command good money for a sr Dev position with it.

Maybe start sniffing around Vue now as well so you're in a good position 12 months from now with it.

Yeah. So far my personal technique has been. Hear about a framework once? - do nothing. Hear about it 4 times? Read an article / overview. See it on 1-2 job postings? Do a tutorial. See it on 5-6 postings? Write something in it, add it to resume.

In fact a small app in Vue is in my very near future because I have started to see it fairly regularly when recruiters contact me.

# ? Jan 28, 2018 16:29

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Lumpy posted:

Counterpoint: Flexbox. Better support, and probably easier to implement.

Knifegrab asked for "most modern" :v:

Webpack 3 question.
So I'm having to rewrite some js with stuff like imports and defining variables so it compiles. This is fine and I'm trying to do it bit by bit.
This is basically my code, but I've changed the names of the files.

code:

module.exports = {
  entry: {
    aPage: './js/aPage.js',
    bPage: ' './js/bPage.js',
    cPage: './js/c.ts',
    vendor:['jquery', 'jquery-validation', ''jquery-lazyload']
  },
  module:{
    loaders:[
      {
        test: /[\/\\]node_modules[\/\\]some-module[\/\\]index\.js$/,
        loader: "imports-loader?define=>false"
      }      
    ],
    rules: [
      {
        test: /\.ts?$/,
        loader: 'ts-loader',
        exclude: /node_modules/
      }
    ]
  },
  plugins: [
    new CleanWebpackPlugin(['/some/filepath/js'])
  ],
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({
      name: "vendor",
      // filename: "vendor.js"
      // (Give the chunk a different name)
  
      minChunks: Infinity,
      // (with more entries, this ensures that no other module
      //  goes into the vendor chunk)
    })
  ],
  output: {
    filename: '[name].js',
    path: path.resolve(__dirname, '/some/filepath/js')
  }  
};

For some reason the moment my entry point contains a single TypeScript file (./js/c.ts), it Webpack then tries to run through and bundle any TypeScript file it can find. It does not try to do that unless cPage: './js/c.ts', is present. I just want it to try and bundle the file(s) I explicitly mentioned.

Also, Webpack 4 beta, with no CommonsChunkPlugin

# ? Jan 29, 2018 15:53

chime_on: Jul 27, 2001

The Merkinman posted:

Knifegrab asked for "most modern"

Webpack 3 question.
So I'm having to rewrite some js with stuff like imports and defining variables so it compiles. This is fine and I'm trying to do it bit by bit.
This is basically my code, but I've changed the names of the files.
code:
module.exports = {
  entry: {
    aPage: './js/aPage.js',
    bPage: ' './js/bPage.js',
    cPage: './js/c.ts',
    vendor:['jquery', 'jquery-validation', ''jquery-lazyload']
  },
  module:{
    loaders:[
      {
        test: /[\/\\]node_modules[\/\\]some-module[\/\\]index\.js$/,
        loader: "imports-loader?define=>false"
      }      
    ],
    rules: [
      {
        test: /\.ts?$/,
        loader: 'ts-loader',
        exclude: /node_modules/
      }
    ]
  },
  plugins: [
    new CleanWebpackPlugin(['/some/filepath/js'])
  ],
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({
      name: "vendor",
      // filename: "vendor.js"
      // (Give the chunk a different name)
  
      minChunks: Infinity,
      // (with more entries, this ensures that no other module
      //  goes into the vendor chunk)
    })
  ],
  output: {
    filename: '[name].js',
    path: path.resolve(__dirname, '/some/filepath/js')
  }  
};
For some reason the moment my entry point contains a single TypeScript file (./js/c.ts), it Webpack then tries to run through and bundle any TypeScript file it can find. It does not try to do that unless cPage: './js/c.ts', is present. I just want it to try and bundle the file(s) I explicitly mentioned.

Also, Webpack 4 beta, with no CommonsChunkPlugin

I think that's Webpack's default behavior while using ts-loader, per the documentation. You should be able to include or exclude files in a tsconfig.json.

# ? Jan 29, 2018 17:40

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

I just spent pretty much the whole day trying to get a auto-complete search function to work.

As I slowly worked through error after error, I eventually came across one which took me no less than 5 loving hours to figure out. I asked other people in the office, no one knew what what causing it. Eventually, at 5:30pm, I twigged that 'response' had been defined as a property in the DOM and was looking for an interface with a property I hadn't implemented. The whole day basically pissed away because I had forgotten to define a simple property.

I'm feeling hella defeated. :eng99:

# ? Jan 29, 2018 18:58

prom candy: Dec 16, 2005; Only I may dance

dupersaurus posted:

Anyone have any resources they could recommend as a sort of React 201 (or, "so I've made my first app, now what?"), especially in regards of how to think like a react dev? I've made a simple app but I can already see some complexity problems with taking it to the next steps. I know how I'd answer the problems in angular, but I don't know if those same ideas hold up in react.

There's a course on egghead called Advanced Component Design Patterns or something like that that I really enjoyed. I think you have to be an egghead member but it's probably worth it. Also just start learning the popular libraries and components that people like: React Router and redux are key to almost any decent sized project.

# ? Jan 29, 2018 19:08

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

prom candy posted:

There's a course on egghead called Advanced Component Design Patterns or something like that that I really enjoyed. I think you have to be an egghead member but it's probably worth it. Also just start learning the popular libraries and components that people like: React Router and redux are key to almost any decent sized project.

Not saying you *shouldn't* learn React Router because it's a de facto standard (for better or worse), but also check out Redux-First-Router because I have switched to using that and I personally find it so much nicer.

# ? Jan 29, 2018 20:45

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

Ape Fist posted:

I just spent pretty much the whole day trying to get a auto-complete search function to work.

As I slowly worked through error after error, I eventually came across one which took me no less than 5 loving hours to figure out. I asked other people in the office, no one knew what what causing it. Eventually, at 5:30pm, I twigged that 'response' had been defined as a property in the DOM and was looking for an interface with a property I hadn't implemented. The whole day basically pissed away because I had forgotten to define a simple property.

I'm feeling hella defeated.

While it can be frustrating in the moment, this is in some ways the best possible outcome, in that you will NOT forget this soon. This will be baked into your soul and whenever a similar issue comes up, you'll know instantly, and will be able to advise as such to other people. It's only a waste of time if you don't learn anything time it.

# ? Jan 29, 2018 22:48

prom candy: Dec 16, 2005; Only I may dance

Lumpy posted:

Not saying you *shouldn't* learn React Router because it's a de facto standard (for better or worse), but also check out Redux-First-Router because I have switched to using that and I personally find it so much nicer.

Learning that the library you learned is no longer the library to know is one of the most important parts of learning the React ecosystem :v:

# ? Jan 30, 2018 06:47

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

dupersaurus posted:

Anyone have any resources they could recommend as a sort of React 201 (or, "so I've made my first app, now what?"), especially in regards of how to think like a react dev? I've made a simple app but I can already see some complexity problems with taking it to the next steps. I know how I'd answer the problems in angular, but I don't know if those same ideas hold up in react.

Echoing this, but maybe a React 301, including something more real-world like a Node.js backend that stores into a database of some description. I'm familiar with all of the concepts from the .NET C# world, but want to learn how to do the same kind of stuff in a purely React/Node.js way. Preferably using Typescript. I know this is a pretty niche request, but maybe something is out there? Happy to pay if it's a paid course or something.

# ? Jan 30, 2018 10:47

prom candy: Dec 16, 2005; Only I may dance

https://learnnode.com/ for the back-end stuff maybe? I'm not a node developer, I just know people like this guy's tutorials. I think you'll have a hard time finding one tutorial that covers all the tech you want to learn at once.

# ? Jan 30, 2018 22:01

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

prom candy posted:

https://learnnode.com/ for the back-end stuff maybe? I'm not a node developer, I just know people like this guy's tutorials. I think you'll have a hard time finding one tutorial that covers all the tech you want to learn at once.

I'm happy with covering several tutorials or courses. Those are just the things I want to learn, happy to learn them via multiple resources. It's just all the examples I see are kind of like "we're going to make an API" and then they make an API in a way that you would never ever make an API in the real world, because they're oversimplifying for the sake of newer learners.

I guess I'm trying to get my head around how all of this stuff comes together to form an actual application and I'm not finding a lot of resources for this.

# ? Jan 30, 2018 22:24

Vincent Valentine: Feb 28, 2006; Murdertime

A nodejs rest api really is that simple though, even connected to a real database. It's only going to be as complicated as you need it to be, and it's only that complicated because of your specific use case. Meaning if you've already done node 101, you will pretty much learn as you build stuff after that.

# ? Jan 30, 2018 22:48

The Fool: Oct 16, 2003

a hot gujju bhabhi posted:

Echoing this, but maybe a React 301, including something more real-world like a Node.js backend that stores into a database of some description. I'm familiar with all of the concepts from the .NET C# world, but want to learn how to do the same kind of stuff in a purely React/Node.js way. Preferably using Typescript. I know this is a pretty niche request, but maybe something is out there? Happy to pay if it's a paid course or something.

Why do you want to mess around with Node when things like .NET MVC and DRF exist?

# ? Jan 30, 2018 23:41

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

I don't know why that person wants to, but it's probably a good idea to learn how to do it in node if there's any chance you'll be in the job market. Node's all over the fuckin place nowadays for some stupid reason.

# ? Jan 31, 2018 00:15

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

The Fool posted:

Why do you want to mess around with Node when things like .NET MVC and DRF exist?

See Thermopyle's post for one reason, but mainly because I want to artificially limit myself to these techs for the sake of learning them in a "jump in the deep end" kinda way.

# ? Jan 31, 2018 08:50

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

I'm having a Stupid Day and want you guys to think for me! I have a list of urls. I send these URLs off to a service to score them. This can take up to a second each, so obviously I don't want to block the UI while this happens because there could be a couple hundred!! Since I do want the UI to update as each URL is processed (a progress bar and showing the results so far) ditching the whole thing off to a WebWorker may not be the best option (but maybe it is?) So how do I do this (this is in React / Redux btw) in a non-blocking way:

JavaScript code:

const scoreURLs = listOfURLs => {
  return ( dispatch, getState ) => {
    listOfURLs.forEach( _url => {
      // this will perform a fetch, then update state via an action 
      // on success or failure
      dispatch( scoreTheUrl( _url ) ); 
    })
  }
}

Is that already going to do what I want because the scoreTheUrl calls return a fetch / Promise? Do I need to setTimeout those calls? Why can't I think today, even though I already had two cups of coffee?

# ? Jan 31, 2018 18:13

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

Lumpy posted:

I'm having a Stupid Day and want you guys to think for me! I have a list of urls. I send these URLs off to a service to score them. This can take up to a second each, so obviously I don't want to block the UI while this happens because there could be a couple hundred!! Since I do want the UI to update as each URL is processed (a progress bar and showing the results so far) ditching the whole thing off to a WebWorker may not be the best option (but maybe it is?) So how do I do this (this is in React / Redux btw) in a non-blocking way:
JavaScript code:
const scoreURLs = listOfURLs => {
  return ( dispatch, getState ) => {
    listOfURLs.forEach( _url => {
      // this will perform a fetch, then update state via an action 
      // on success or failure
      dispatch( scoreTheUrl( _url ) ); 
    })
  }
}
Is that already going to do what I want because the scoreTheUrl calls return a fetch / Promise? Do I need to setTimeout those calls? Why can't I think today, even though I already had two cups of coffee?

You want to attach handler code to each scoreTheUrl(_url).

code:

scoreTheUrl(_url).then( (res) => {
	// update individual score
	// update progress bar
});

Skandranon fucked around with this message at 18:30 on Jan 31, 2018

# ? Jan 31, 2018 18:27

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Skandranon posted:

You want to attach handler code to each scoreTheUrl(_url).
code:
scoreTheUrl(_url).then( (res) => {
	// update individual scode
	// update progress bad
});

That already happens like so:

JavaScript code:

export const scoreTheUrl = ( url, dispatch  ) => {
  return fetchUrlScore( urlL ) 
  .then( scores => {
            dispatch( receviedScoresForUrl( url,  scores ) );
  })
  .catch( error => {
            dispatch( urlScoreFailed( url ) );
  });
};

So I should be okay? (Other than hitting the concurrent # of ajax request limit in the browser and having them all pile up in a queue but that's for the browser to handle!)

# ? Jan 31, 2018 18:35

Adbot: ADBOT LOVES YOU

# ? Jun 10, 2024 09:41

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

Lumpy posted:

So I should be okay? (Other than hitting the concurrent # of ajax request limit in the browser and having them all pile up in a queue but that's for the browser to handle!)

I suppose? If you end up having a LOT of requests (1000s), you might want to consider implementing a queue so you issue them in batches, but otherwise should work fine for less than that. The browser won't intelligently limit this, it will just run out of memory and die.

# ? Jan 31, 2018 18:59

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »