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 »

Fellatio del Toro: Mar 21, 2009

Is there something I'm missing that makes configuring Angular TestBeds not a massive headache? Having to create a test module with the dependencies for every child component ends up taking more time than actually writing the tests.

# ? Feb 11, 2017 02:15

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 08:07

luchadornado: Oct 7, 2004; A boombox is not a toy!

Munkeymon posted:

This is what you're talking about, right?

That's exactly what I'm talking about, thanks. The highest rated answer suggests using

code:

import * as obj

, which is great and totally worked for us up until now. Unfortunately it won't work with spec-compliant ES6 modules. Long story short, Babel 5 allowed this to work, and Babel 6 now provides a flag to turn on spec mode that breaks this. Supporting the spec probably seems the right way to go, but I really don't want to bring in something like proxyquire or rewire just to stub things.

Plavski posted:

My tech lead gets pissed when I bring him examples of complex js optimizations we could make where the difference is 0.01s over 10,000 iterations. "I'd rather have readable code that's slower than unreadable nonsense no-one else will be able to read after we fire you for writing unreadable code."

Doesn't stop me tho

Intern/Junior Developer: writes garbage code that is slow
Developer: writes garbage code that is fast
Senior Developer: writes garbage code, but less of it, and it is fast enough to meet the needs of the business

You should strive to (intelligently and professionally) push back on business requirements, leverage 3rd party libraries when available, lean on the language and framework to provide as many guarantees and to write as little code as possible, and keep it as simple as possible. I've heard this referred to as design by guarantee, which isn't a real thing. The more code you can not write due to guarantees, the fewer bugs you'll have, and the more you can work on the interesting problems in your domain. If your micro optimization doesn't provide tangible value to the company, you wasted your time and probably other people's time.

luchadornado fucked around with this message at 02:59 on Feb 11, 2017

# ? Feb 11, 2017 02:35

Roadie: Jun 30, 2013

ddiddles posted:

Thanks man.

I have the bad habit of wanting the first code I write to be the final code I write, so I just sit there wringing my hands thinking "I'm probably doing this wrong", and it stops me from actually getting anything done.

The cure to this one is to do a project where you literally have no idea of how half of it should work when you start out because the client hasn't told you yet and so you just go "gently caress it" and put in stuff that more or less works and go back and change it later (and then again later when the client inevitably changes their mind well after they give you the full spec).

# ? Feb 11, 2017 05:58

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

Thermopyle posted:

That diagram could use someone going over it a few more times, but...it seems pretty straightforward? At least when it comes to forms.

Really, it's surprising how complex forms actually are no matter the technology you're using, and Redux is one of the ways that make them simpler to handle.

Totally agree. People who think forms are easy have just been making terrible forms.

# ? Feb 11, 2017 06: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

Plavski posted:

My tech lead gets pissed when I bring him examples of complex js optimizations we could make where the difference is 0.01s over 10,000 iterations. "I'd rather have readable code that's slower than unreadable nonsense no-one else will be able to read after we fire you for writing unreadable code."

Doesn't stop me tho

He's right.

# ? Feb 11, 2017 06:03

piratepilates: Mar 28, 2004; So I will learn to live with it. Because I can live with it. I can live with it.

Helicity posted:

That's exactly what I'm talking about, thanks. The highest rated answer suggests using
code:
import * as obj
, which is great and totally worked for us up until now. Unfortunately it won't work with spec-compliant ES6 modules. Long story short, Babel 5 allowed this to work, and Babel 6 now provides a flag to turn on spec mode that breaks this. Supporting the spec probably seems the right way to go, but I really don't want to bring in something like proxyquire or rewire just to stub things.

The need to do this concerns me a bit. Needing to mock out something that you're importing strikes me as a sign that the dependency shouldn't be imported but instead passed in.

I mean in the linked example, he has a class called Widget that is importing a function to retrieve data from a server. The class has a constructor with no arguments that could take that function as an import, or just call the function first and create the Widget with the data.

Making the side-effect-ful dependency an object passed in to the constructor instead of a static import would also make it much clearer what the widget needs to do its job too, and what kind of side effects it will have. Plus you won't need to worry about mocks since you just pass in data as it would be normally.

# ? Feb 11, 2017 06:43

luchadornado: Oct 7, 2004; A boombox is not a toy!

piratepilates posted:

The need to do this concerns me a bit. Needing to mock out something that you're importing strikes me as a sign that the dependency shouldn't be imported but instead passed in.

I mean in the linked example, he has a class called Widget that is importing a function to retrieve data from a server. The class has a constructor with no arguments that could take that function as an import, or just call the function first and create the Widget with the data.

Making the side-effect-ful dependency an object passed in to the constructor instead of a static import would also make it much clearer what the widget needs to do its job too, and what kind of side effects it will have. Plus you won't need to worry about mocks since you just pass in data as it would be normally.

I agree, and so do most of my co-workers. Most of my team has experience in C#, or at least Java, and we keep saying "this kind of feels like we need DI, but ugh..."

Where that breaks down, and what is currently stumping us, is when you bring functional programming into it - our stack is React, react-router, and redux. First, we don't have baked in DI like angular or aurelia do. My first guess is to do some sort of monadic, higher order function type thing to be able to wrap any function and pass in parameters as a sort of DI-lite.

I guess the real question is: how should you manage your inter and intra-module dependencies in JavaScript while embracing the more functional aspects of the language, and if DI is the answer, what are the best options there when your framework doesn't provide it?

# ? Feb 11, 2017 14:25

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

What do you guys recommend for Angular R&D?
I've still super green on it and trying to find an answer for my question* I either get:
Something Unrelated
The Answer in AngularJS
The Answer in a pre-release of Angular 2 that no longer works.

*The question is, how do I make a <select> where the values and text are just integers. From 1 to X (X i suppose could be hardcoded at 10, but ideally object.max if object.max < 10 (otherwise 10) )

# ? Feb 16, 2017 15:57

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

The Merkinman posted:

What do you guys recommend for Angular R&D?
I've still super green on it and trying to find an answer for my question* I either get:
Something Unrelated
The Answer in AngularJS
The Answer in a pre-release of Angular 2 that no longer works.

*The question is, how do I make a <select> where the values and text are just integers. From 1 to X (X i suppose could be hardcoded at 10, but ideally object.max if object.max < 10 (otherwise 10) )

What version of Angular are you looking for? 2? Angular doesn't care what types your values/text are. You can use ng-options or even ng-repeat to do it.

# ? Feb 16, 2017 16: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!

HaB posted:

What version of Angular are you looking for? 2? Angular doesn't care what types your values/text are. You can use ng-options or even ng-repeat to do it.

I'm looking for version 2. Aren't ng-options and ng-repeat AngularJS 1.X things?
I see them done with:

code:

<option *ngFor="let object of objects" [value]="object.value">

but I don't have a list of objects, just a list of numbers. I guess I have to make some new function that returns just a simple list of numbers to satisfy Angular?

# ? Feb 16, 2017 16:34

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

The Merkinman posted:

I'm looking for version 2. Aren't ng-options and ng-repeat AngularJS 1.X things?
I see them done with:
code:
<option *ngFor="let object of objects" [value]="object.value">
but I don't have a list of objects, just a list of numbers. I guess I have to make some new function that returns just a simple list of numbers to satisfy Angular?

Numbers are objects...

code:

<option *ngFor="let n of numbers" [value]="n">

# ? Feb 16, 2017 16:46

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.'

The Merkinman posted:

I see them done with:
code:
<option *ngFor="let object of objects" [value]="object.value">
but I don't have a list of objects, just a list of numbers. I guess I have to make some new function that returns just a simple list of numbers to satisfy Angular?

If you already have a list of numbers, then the "object" there is a red herring, it's just iterating over a list. In JS syntax *ngFor is a for...of statement. If you're looking to emulate for (var i = 0; i < x; i++), then yeah you'll have to generate a list and iterate over it.

# ? Feb 16, 2017 16:48

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

dupersaurus posted:

If you already have a list of numbers, then the "object" there is a red herring, it's just iterating over a list. In JS syntax *ngFor is a for...of statement. If you're looking to emulate for (var i = 0; i < x; i++), then yeah you'll have to generate a list and iterate over it.

Thanks yeah, I came to the realization that I'm used to doing what you mentioned, but I have to generate that thing elsewhere then use it.

EDIT: What about my original question of reseourches for R&D (and documentation) I know the angular docs, but not sure how to 'phrase' a question so I'd find it there.

# ? Feb 16, 2017 17:19

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

The Merkinman posted:

Thanks yeah, I came to the realization that I'm used to doing what you mentioned, but I have to generate that thing elsewhere then use it.

EDIT: What about my original question of reseourches for R&D (and documentation) I know the angular docs, but not sure how to 'phrase' a question so I'd find it there.

I usually start with relatively straightforward questions "how do I make dropdown in Angular" and go from there, keeping in mind that most examples will be poo poo and tell you really dumb things to do, but sometimes there will be an idea or clue in them to figure out something not so lovely.

# ? Feb 16, 2017 17:24

ddiddles: Oct 21, 2008; Roses are red, violets are blue, I'm a schizophrenic and so am I

Is there a standard way of conditionally rendering a class based components contents in React?

I have a component that will render three completely different views depending on the props passed into it from the redux connect function, (loading indicator, nothing found indicator, and then the data itself).

I've been going back and forth, moving all the conditional stuff into a method on the class, and having the render method just call that method every time the components rendered, and on some components, I put the conditional logic inside the render method itself.

Both technically work, and the only reason I've mixed and matched is because I usually forget what I did on a previous component.

I'd like to stick to one pattern as much as possible, and if there's a generally accepted way to do it I'd rather use that way.

# ? Feb 18, 2017 23:19

luchadornado: Oct 7, 2004; A boombox is not a toy!

Keep as much logic as you can out of components, and the logic as close as you can to the source. In a perfect world, most of your components will be pure functions and have no state.

code:

const currentView = state.isLoading ? loadingAnimation : dataView;

return <div>{currentView}</div>;

Slightly ignoring the advice above, having a model with no items to display vs. with items to display is fine logic to keep in the component. It would be something similar:

code:

const dataToDisplay = data.items && data.items.length
  ? data.items.map((x, index) => <li key={index}>{x.text}</li>)
  : <li><span>No items found</span></li>;

return <ul>{dataToDisplay}</ul>

or whatever. Having a special method to do that sounds annoying. Unless I'm misunderstanding what you're trying to do.

# ? Feb 19, 2017 00:38

ddiddles: Oct 21, 2008; Roses are red, violets are blue, I'm a schizophrenic and so am I

Most of my components have no state of their own, more often then not they are getting called by their Container, which is connected to the redux store.

I guess it would help if I explained what Im doing.

For example, I have a Companies container that connects to my redux store. It calls an action generator with componentWillMount() that grabs a list of all the companies I have stored in firebase, formats that data into an array and dispatches an action with that array as a payload, or dispatches a different action if there wasnt any data returned from FB or there was an error. These actions set some flags on the store that the Companies container also has as props.

So in my render method on the Companies container, I have the following logic:

1. If this.props.flags.started is true, return JSX that renders a loading spinner.
2. If this.props.flags.failure is true, return JSX that renders a message saying there wasnt anything found.
3. If an array exists on this.props.companies, then render that list.
4. If none of these are true, it means that the initial action didn't get fired off and theres something wrong with the code.

I have another container that grabs a different list of data, but the logic for formatting and displaying it is the same, and in that container, all the logic above is in a renderView() method, and the render() method calls that.

Just wondering which way was more "proper", or does it even matter?

# ? Feb 19, 2017 01:47

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

ddiddles posted:

Most of my components have no state of their own, more often then not they are getting called by their Container, which is connected to the redux store.

I guess it would help if I explained what Im doing.

For example, I have a Companies container that connects to my redux store. It calls an action generator with componentWillMount() that grabs a list of all the companies I have stored in firebase, formats that data into an array and dispatches an action with that array as a payload, or dispatches a different action if there wasnt any data returned from FB or there was an error. These actions set some flags on the store that the Companies container also has as props.

So in my render method on the Companies container, I have the following logic:

1. If this.props.flags.started is true, return JSX that renders a loading spinner.
2. If this.props.flags.failure is true, return JSX that renders a message saying there wasnt anything found.
3. If an array exists on this.props.companies, then render that list.
4. If none of these are true, it means that the initial action didn't get fired off and theres something wrong with the code.

I have another container that grabs a different list of data, but the logic for formatting and displaying it is the same, and in that container, all the logic above is in a renderView() method, and the render() method calls that.

Just wondering which way was more "proper", or does it even matter?

There's no "right" way to do it since it will vary so much based on your app. One approach is to abstract the common patterns ("show a Loading if I'm loading or something else if not") into components (or base classes) al la:

JavaScript code:

const LoadingOrChildren = ({ isLoading, children }) => {
    return isLoading ? <LoadingIndicatorThing /> : children;
}

Then use it like:

JavaScript code:

<LoadingOrChildren isLoading={amILoading}>
    <ComponentThatRendersList stuff={listOfStuff} />
</LoadingOrChildren>

You can extend that to having components that show "no data" views if the list is empty:

JavaScript code:

const ListOrNoDataMessage = ({ hasStuff, children, message }) => {
    return hasStuff ?  children : <h1>{ message }</h1>;
}

// ...

<ListOrNoDataMessage message="no stuff to show" hasStuff={!!listOfStuff.length}>
    <ComponentThatRendersList stuff={listOfStuff} />
</ListOrNoDataMessage>

Combine them into one awesome mega "Show a loader if loading, show a message if empty, show the list otherwise" component:

JavaScript code:

<LoadingOrChildren isLoading={amILoading}>
    <ListOrNoDataMessage message="no stuff to show" hasStuff={listOfStuff.length}>
         <ComponentThatRendersList stuff={listOfStuff} />
    </ListOrNoDataMessage>
</LoadingOrChildren>

Or compose LoadingOrChildren and ListOrNoDataMessage into a single component since you'll use them together all the time. You could also make base container classes that implement these behaviors and use those as your container components. Again, up to what makes sense for you.

The key (for me at least) is to think of small things and compose compose compose!

# ? Feb 19, 2017 19:35

an skeleton: Apr 23, 2012; scowls @ u

Has anyone worked with/built an api adhering to this spec before?

http://jsonapi.org/

(Any advice or guidance around using this type of API is appreciated!)

# ? Feb 21, 2017 22:13

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

I have. I'm not sure what you're looking for. If you strip out all the optional bits, it's pretty straight-forward to hand-roll on both the front- and back-end.

Don't do that, though; just look for your language(s) in the list of implementations on that site.

# ? Feb 21, 2017 23:06

luchadornado: Oct 7, 2004; A boombox is not a toy!

I've worked with it before. It's not a gamechanger, but I didn't find any obvious downsides to it and it solves the primary goal of preventing bikeshedding - so it's cool I guess? Even if you ignore the part that takes extra effort, the links, it's helpful if just to standardize the response and error codes/content.

# ? Feb 22, 2017 00:20

an skeleton: Apr 23, 2012; scowls @ u

I'm really not looking for anything except for any super-important advice that i may not get from scanning the documentation. It does look like the redux implementation library uses redux-thunk which we are currently not using in favor of redux-saga, so I'm not sure if we'll have to roll our own translation to/from the API on the front-end.

# ? Feb 22, 2017 00:46

luchadornado: Oct 7, 2004; A boombox is not a toy!

Tying API data standards to implementation middleware for handling asynchronicity sounds horrible and that's why I hate working in front-end stuff these days. Not a slight on you/your team, more of on the JS world.

# ? Feb 22, 2017 01:02

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

Ellie, an embeddable jsfiddle-a-like for Elm. Even installs packages.

# ? Feb 26, 2017 02:01

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

Doc Hawkins posted:

Ellie, an embeddable jsfiddle-a-like for Elm. Even installs packages.

I desperately want to make a Real Thing in elm. Maybe my next side project should I ever finish the three languishing on my hard drive currently.

# ? Feb 26, 2017 06:46

Plavski: Feb 1, 2006; I could be a revolutionary

What do you guys use for your unit/e2e testing?

# ? Feb 26, 2017 12:38

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

Plavski posted:

What do you guys use for your unit/e2e testing?

My brain

# ? Feb 26, 2017 19:19

an skeleton: Apr 23, 2012; scowls @ u

Plavski posted:

What do you guys use for your unit/e2e testing?

for our react app --
unit -- karma/mocha/chai/enzyme and a couple of karma plugins like karma-webpack

e2e - none yet :troll:

# ? Feb 26, 2017 23:14

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Plavski posted:

What do you guys use for your unit/e2e testing?

A small army of button-clickers in India. Tests run automatically overnight and generate bug reports and everything.

# ? Feb 27, 2017 17:22

Fellatio del Toro: Mar 21, 2009

We use Karma/Protractor

# ? Feb 27, 2017 18:17

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

I'm considering going back to Jest for unit testing...it seems to have improved a lot since I last used it a couple years ago.

# ? Feb 27, 2017 22:53

luchadornado: Oct 7, 2004; A boombox is not a toy!

mocha/sinon/chai/enzyme primarily, although I'm personally trying to limit the use of sinon by leveraging function composition that essentially acts like dependency injection. For personal stuff I prefer should to chai.

Our legacy stuff uses karma/phantom and is a pain in the rear end - mainly because it's "unit tests" that are actually more like convoluted integration tests of jQuery widget garbage wrapped in Angular.

For anything non-unit test we're using Cucumber, but it is even more problematic than the karma/phantom stuff. Our company wrote years and years worth of Cucumber tests and now our testing monolith is almost as scary as our code monolith. We're had to devote several weeks to reading "Art of Unit Testing" and "Working with Legacy Code" to try and get people up to speed on why this stuff is bad and how to change it.

I briefly looked at testdouble, but the author brags about creating testing frameworks from the ground up several times and has some horrible opinions on testing via Reddit/Twitter, so I've automatically discounted it as a piece of poo poo based on that.

# ? Feb 28, 2017 14:06

Kekekela: Oct 28, 2004

Thermopyle posted:

I'm considering going back to Jest for unit testing...it seems to have improved a lot since I last used it a couple years ago.

I'm going to be trying to implement Jest on my current project this week. :hfive:

# ? Feb 28, 2017 17:05

Pollyanna: Mar 5, 2005; Milk's on them.

Today we had some contractors from Cognitect over to help us with our React-Redux components and one of the more illuminating revelations of the meeting was that our tech lead did not understand how React and Redux worked. :shepicide:

The contractors shared my horror and frustration at our implementations and code and naturally, it turns out that we're going slow due to the tech lead misunderstanding the point of the framework. No wonder we've been so frustrated and unproductive. I am genuinely kind of pissed off and annoyed here. I'm even more worried for my coworker whose first exposure to front end has been so poor for such a dumb reason.

Just another thing on the :yotj:

pile.

# ? Feb 28, 2017 21:24

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

Pollyanna posted:

Today we had some contractors from Cognitect over to help us with our React-Redux components and one of the more illuminating revelations of the meeting was that our tech lead did not understand how React and Redux worked.

Based on what you've been asking / telling us in this thread we could have told you that for half what they charged you!

# ? Feb 28, 2017 22:21

Pollyanna: Mar 5, 2005; Milk's on them.

Lumpy posted:

Based on what you've been asking / telling us in this thread we could have told you that for half what they charged you!

Now it's formalized. But will anything actually change? No. A haiku I guess.

# ? Feb 28, 2017 22:51

Forgall: Oct 16, 2012; by Azathoth

Pollyanna posted:

Today we had some contractors from Cognitect over to help us with our React-Redux components and one of the more illuminating revelations of the meeting was that our tech lead did not understand how React and Redux worked. The contractors shared my horror and frustration at our implementations and code and naturally, it turns out that we're going slow due to the tech lead misunderstanding the point of the framework. No wonder we've been so frustrated and unproductive. I am genuinely kind of pissed off and annoyed here. I'm even more worried for my coworker whose first exposure to front end has been so poor for such a dumb reason.

Just another thing on the pile.

Could you expound on this a little? I'm learning react and redux and I'm worried I might be misunderstanding things as well.

# ? Feb 28, 2017 23:00

Kekekela: Oct 28, 2004

Forgall posted:

Could you expound on this a little? I'm learning react and redux and I'm worried I might be misunderstanding things as well.

If at all possible I'd get a firm grasp on React before learning Redux.

# ? Feb 28, 2017 23:01

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

Forgall posted:

Could you expound on this a little? I'm learning react and redux and I'm worried I might be misunderstanding things as well.

The React and the Redux docs are both really good and not terribly large, so it's hard for me to understand how someone could be a tech lead and not understand how they worked. I mean, there are a decent number of moving parts and I embarrassingly always have to re-read or skim the docs when starting a new project, but just understanding how they works shouldn't be too hard to pick up. Of course, it's a little difficult for someone who has experience to remember exactly what its like to come at something with no experience...but hell I understand how they work and I'm nothing special.

A good thing to do in addition to reading the docs is watching these videos by Dan Abramov (creator of Redux): https://egghead.io/instructors/dan-abramov?order=desc&page=1

Kekekela posted:

If at all possible I'd get a firm grasp on React before learning Redux.

Also, this might be a good idea.

# ? Feb 28, 2017 23:06

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 08:07

Forgall: Oct 16, 2012; by Azathoth

Kekekela posted:

If at all possible I'd get a firm grasp on React before learning Redux.

Thermopyle posted:

A good thing to do in addition to reading the docs is watching these videos by Dan Abramov (creator of Redux): https://egghead.io/instructors/dan-abramov?order=desc&page=1

Thank you, I've been working through those videos. I'm just curious in what way things went wrong with Pollyanna's project.

# ? Feb 28, 2017 23:11

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

«‹›235 »