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 »

my bony fealty: Oct 1, 2008

Edge still sucks

I really wanted to like it but it just feels clunky and has bad aesthetics. Also lacks support for stuff...no clip-path on non-svg elements! Have had issues with flexbox too.

MS should just abandon the browser game.

# ? Sep 7, 2018 17:29

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 17:53

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

Ape Fist posted:

Imagine if Google went with Dart over TypeScript in Angular.

a world where Angular never took off

# ? Sep 7, 2018 17:58

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

Gildiss posted:

https://reactjs.org/docs/react-component.html#componentwillunmount

Nm that was right, handle the cancelling of the request in here.

That's what we're doing now

JavaScript code:

  mounted = false;

 componentDidMount() {
     this.mounted = true;
     doRequest()
         .then(() => {
           if(!this.mounted === false) {return;}
	   this.setState({ loading: false })
         })
       .catch()
  }

  componentWillUnmount() {
        this.mounted = false;
   }

but it's an antipattern, apparently

# ? Sep 7, 2018 21:18

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.

quick thing on the lifecycle hooks in react, correct me if I'm wrong:

code:

	componentDidMount() { 
		// After the component has run through its default methods/state set, do this?
	}
		(ngOnInit)

	componentDidUpdate() {
		// After a state change or method execution, do this?
	}
		(ngOnChanges)

	componentDidUnmount() {
		// After a component is destroyed, do this?
	}
		(ngOnDestroy)

# ? Sep 7, 2018 22:00

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

Anyone else think Chrome latest is rendering text taller than it was? I think I'm seeing the bottom few pixels cut off in some embedded tweets, probably as a result.

# ? Sep 7, 2018 23:39

Love Stole the Day: Nov 4, 2012; Please give me free quality professional advice so I can be a baby about it and insult you

Grump posted:

That's what we're doing now

JavaScript code:

  mounted = false;

 componentDidMount() {
     this.mounted = true;
     doRequest()
         .then(() => {
           if(!this.mounted === false) {return;}
	   this.setState({ loading: false })
         })
       .catch()
  }

  componentWillUnmount() {
        this.mounted = false;
   }

but it's an antipattern, apparently

I could be wrong but if I remember right it is possible to manually create and cancel a promise before it is completed. Since it seems that your doRequest() function seems to return a promise (which I think is why you use `.then( () => { .. } )` ) maybe you can set its promise to a variable in the parent component and then manually cancel it from within the child component when it unmounts? Though in that case you'd have to change from an anonymous function to a named one: something like `fn_OnRequestReceived()` or whatever.

I might be misremembering how Promises work off the top of my head, though.

# ? Sep 8, 2018 01:06

Dominoes: Sep 20, 2007

my bony fealty posted:

Edge still sucks

I really wanted to like it but it just feels clunky and has bad aesthetics. Also lacks support for stuff...no clip-path on non-svg elements! Have had issues with flexbox too.

MS should just abandon the browser game.

It's nice having an epub and PDF reader built into the OS.

# ? Sep 8, 2018 01:13

Gildiss: Aug 24, 2010; Grimey Drawer

Love Stole the Day posted:

I could be wrong but if I remember right it is possible to manually create and cancel a promise before it is completed. Since it seems that your doRequest() function seems to return a promise (which I think is why you use `.then( () => { .. } )` ) maybe you can set its promise to a variable in the parent component and then manually cancel it from within the child component when it unmounts? Though in that case you'd have to change from an anonymous function to a named one: something like `fn_OnRequestReceived()` or whatever.

I might be misremembering how Promises work off the top of my head, though.

Yes, this is the way I would go about it, set a state variable to hold the Promise and and in unmount cancel the request.

# ? Sep 8, 2018 02:57

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 realized that react treats

this = (kind) => {
of function
}

differently than

this(kind) {
of function
}

specifically when it comes to scoping in-JSX function references.

If you use the first kind of syntax, you won't need do this.function = this.function.bind(this) in the constructor(), but if you use the second you will.

Anyone know why?

(and what the major consequences of using function = ( argument ) => { result } over function(argument) { result } are? I always thought they were relatively interchangeable)

# ? Sep 8, 2018 10:23

SimonChris: Apr 24, 2008; The Baron's daughter is missing, and you are the man to find her. No problem. With your inexhaustible arsenal of hard-boiled similes, there is nothing you can't handle.; Grimey Drawer

Grump posted:

That's what we're doing now

JavaScript code:

  mounted = false;

 componentDidMount() {
     this.mounted = true;
     doRequest()
         .then(() => {
           if(!this.mounted === false) {return;}
	   this.setState({ loading: false })
         })
       .catch()
  }

  componentWillUnmount() {
        this.mounted = false;
   }

but it's an antipattern, apparently

The best solution is to move the request into Redux or whatever state-handling framework you are using.
You shouldn't be fetching asynchronous data into local component state in the first place.
Even if you resolve this issue, you will be doing the same request over and over as the user navigates back and forth, instead of just caching the data after the first time.

If moving the request isn't possible, then I agree with everyone else that you have to either figure out a way to cancel the request, or just keep using the "anti-pattern" depending on the details of what you are doing.

# ? Sep 8, 2018 10:40

Vincent Valentine: Feb 28, 2006; Murdertime

Ape Fist posted:

I just realized that react treats

this = (kind) => {
of function
}

differently than

this(kind) {
of function
}

specifically when it comes to scoping in-JSX function references.

If you use the first kind of syntax, you won't need do this.function = this.function.bind(this) in the constructor(), but if you use the second you will.

Anyone know why?

(and what the major consequences of using function = ( argument ) => { result } over function(argument) { result } are? I always thought they were relatively interchangeable)

That's just how arrow functions work. The arrow uses the "this" of the scope in which it was defined. It is a wonderful addition to JavaScript and more often than not prevents surprises.

https://reactarmory.com/answers/when-to-use-arrow-functions
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions

# ? Sep 8, 2018 12:01

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Ape Fist posted:

I just realized that react treats

this = (kind) => {
of function
}

differently than

this(kind) {
of function
}

specifically when it comes to scoping in-JSX function references.

If you use the first kind of syntax, you won't need do this.function = this.function.bind(this) in the constructor(), but if you use the second you will.

Anyone know why?

(and what the major consequences of using function = ( argument ) => { result } over function(argument) { result } are? I always thought they were relatively interchangeable)

it's nothing to do with react, arrow functions are an es6 feature.

the big benefit is avoiding all the var self=this in closures, e.g. in vanilla js

code:

var self = this;
var note = document.createElement('div');
note.addEventListener('mousedown', function(e) { return self.onMouseDown(e) }, false);
note.addEventListener('click', function() { return self.onNoteClick() }, false);

the value of 'this' in these functions... would be window. which is almost certainly not what you want, which is why you'd use the self = this.

code:

var note = document.createElement('div');
note.addEventListener('mousedown', (e) => this.onMouseDown(e) , false);
note.addEventListener('click', () => this.onNoteClick() }, false);

is much nicer.

Bruegels Fuckbooks fucked around with this message at 13:27 on Sep 8, 2018

# ? Sep 8, 2018 13:25

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.

oh right.

# ? Sep 8, 2018 14:56

Moto42: Jul 14, 2006

Not knowing about arrow functions and this/that/self cost me hours of frustrating debugging my first day of learning javascript.

Ironically, the first solution I thought of was declaring 'that: this and using that, but I immediately thought to myself
"Nah, that's some hacky thing you're doing because your a newb. Knuckle down and find out what's really wrong with your code. Do it right."

A little under three months later and I'm going "Fuckit, just make it work first, then make it right later... maybe."

Moto42 fucked around with this message at 01:52 on Sep 10, 2018

# ? Sep 10, 2018 01:48

Love Stole the Day: Nov 4, 2012; Please give me free quality professional advice so I can be a baby about it and insult you

Moto42 posted:

A little under three months later and I'm going "Fuckit, just make it work first, then make it right later... maybe."

With my self-learning experience, I read a thing pretty early on that I still try to stick to. It goes something like:

When making stuff, you should do it in three phases, in this order:

Make it work
Make it fast
Make it pretty

# ? Sep 10, 2018 02:04

Mr Shiny Pants: Nov 12, 2012

Love Stole the Day posted:

With my self-learning experience, I read a thing pretty early on that I still try to stick to. It goes something like:

When making stuff, you should do it in three phases, in this order:

Make it work
Make it fast
Make it pretty

I agree, but I also would like to point out that sometimes making it look pretty keeps you working on it longer instead of getting disappointed with it and abandoning it altogether.

YMMV of course.

# ? Sep 10, 2018 09:17

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

So this is more of a general opinion question:

In my professional life, I am rarely called upon to both design a back-end API and code a front end for it. Make changes to an existing API? Sure, but by and large, I am considered "full stack" only in that I can work on both, but I am rarely completely responsible for both.

On my latest personal project however, I am doing everything myself, and that has raised some questions regarding overall approach. My initial pass was: back-end first. Basically: I have this data, here's some endpoints to get it out, front-end must deal with the rest. The issue is, I find I am doing entirely too much logic on my front-end - or at least what feels like too much logic.

For example I have a consolidated search which returns results from multiple sources - a local one, and some remote ones. Since the remote sources aren't mine, I don't have control over what field names appear. But as I am putting together the front-end pages, I am doing an awful lot of:

code:

if (data.source === 'LOCAL')

and it's started to feel really clunky. So last night I started refactoring the back-end to basically make all the search result items have the same shape, no matter what the source is. I am hoping this will greatly simplify both GraphQL queries as well as template logic.

So I guess my question is: assuming YOU are the one-stop-shop covering soup to nuts on a given app - what's your usual approach?

# ? Sep 10, 2018 11:48

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

HaB posted:

So this is more of a general opinion question:

In my professional life, I am rarely called upon to both design a back-end API and code a front end for it. Make changes to an existing API? Sure, but by and large, I am considered "full stack" only in that I can work on both, but I am rarely completely responsible for both.

On my latest personal project however, I am doing everything myself, and that has raised some questions regarding overall approach. My initial pass was: back-end first. Basically: I have this data, here's some endpoints to get it out, front-end must deal with the rest. The issue is, I find I am doing entirely too much logic on my front-end - or at least what feels like too much logic.

For example I have a consolidated search which returns results from multiple sources - a local one, and some remote ones. Since the remote sources aren't mine, I don't have control over what field names appear. But as I am putting together the front-end pages, I am doing an awful lot of:
code:
if (data.source === 'LOCAL')
and it's started to feel really clunky. So last night I started refactoring the back-end to basically make all the search result items have the same shape, no matter what the source is. I am hoping this will greatly simplify both GraphQL queries as well as template logic.

So I guess my question is: assuming YOU are the one-stop-shop covering soup to nuts on a given app - what's your usual approach?

in this case with the multiple datasources, you probably make it so your front end only communicates with one server, and that server communicates with all the others service to service (you can do service to service graphql queries, or you could have the service act as a reverse proxy and aggregate results). if you communicate with multiple datasources on the client, it can greatly increase the complexity of both the client code and the server code.

however, the problem is going either direction (starting with client code or starting with server code) isn't going to give you that insight until you do the project and it's hosed - like, for instance, I've seen a ton of architectural quagmires in retrospect where people don't understand that message brokers like rabbitmq exist and try to make components communicate through a disgusting mess of ajax calls, and that isn't really solvable by going front-end - back-end or back-end to front end.

# ? Sep 10, 2018 13:17

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

Dominoes posted:

It's nice having an epub and PDF reader built into the OS.

I didn't know Edge supported epub - that's pretty neat.

my bony fealty posted:

Edge still sucks

I really wanted to like it but it just feels clunky and has bad aesthetics. Also lacks support for stuff...no clip-path on non-svg elements! Have had issues with flexbox too.

MS should just abandon the browser game.

loling at the notion of shipping an OS without a browser in this century

# ? Sep 10, 2018 13:57

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

HaB posted:

backend vs frontend

When I'm developing the front and backends on my own, I start with the backend, but you should definitely be prepared to hop back and forth between the back and the front as you're fleshing out your ideas.

I also make my frontend and backend completely separate projects...their own repos, their own folders on my PC, etc. This helps enforce the separateness of them in my mind.

# ? Sep 10, 2018 15:09

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

Bruegels Fuckbooks posted:

in this case with the multiple datasources, you probably make it so your front end only communicates with one server, and that server communicates with all the others service to service (you can do service to service graphql queries, or you could have the service act as a reverse proxy and aggregate results). if you communicate with multiple datasources on the client, it can greatly increase the complexity of both the client code and the server code.

Oh no there's only one server the client knows about. The server is responsible for aggregating the multiple sources.

Thermopyle posted:

When I'm developing the front and backends on my own, I start with the backend, but you should definitely be prepared to hop back and forth between the back and the front as you're fleshing out your ideas.

I also make my frontend and backend completely separate projects...their own repos, their own folders on my PC, etc. This helps enforce the separateness of them in my mind.

Yeah this is what I am starting to realize. I have them as two separate repos as well. K. I was starting to figure there's no One True Approach.

# ? Sep 10, 2018 15:25

rujasu: Dec 19, 2013

Munkeymon posted:

loling at the notion of shipping an OS without a browser in this century

I don't think MS will ever give up the browser game either, but if they did, it would surely mean shipping with Firefox or Chrome.

# ? Sep 10, 2018 15:28

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

That reminds me of the GPS fleet tracker I use on my one company vehicle for my one employee. (not a web dev or technology company)

It's made by TrackmateGPS and it's something like this. They completely redesigned their website 6 months ago and its terrible.

It does all sorts of requests from the frontend that should be done by the backend and aggregated into one request from the frontend. For example, the history report you can do makes this list of all the events...ignition on, ignition off, stops, gps updates, etc. It does multiple requests for each event to their own servers and to Google APIs. So, it's not uncommon for a history report to make several thousand requests from your browser which makes all other tabs unusable while they wait for a free socket to make their own requests on.

Also, the scroll position on this stupid list of events resets on each request so you have to just leave the page alone until it finishes.

# ? Sep 10, 2018 15:32

my bony fealty: Oct 1, 2008

rujasu posted:

I don't think MS will ever give up the browser game either, but if they did, it would surely mean shipping with Firefox or Chrome.

Yeah considering the first thing everyone does with a new Windows machine is open up Edge to download Chrome, why not just cut out that 2 minute annoyance. Ship with Chrome and Firefox preinstalled. Throw Brave in there if you wanna be wild.

Bing is good tho

# ? Sep 10, 2018 15:36

duz: Jul 11, 2005; Come on Ilhan, lets go bag us a shitpost

HaB posted:

Oh no there's only one server the client knows about. The server is responsible for aggregating the multiple sources.

Yeah this is what I am starting to realize. I have them as two separate repos as well. K. I was starting to figure there's no One True Approach.

Normalizing foreign data before any of your business logic sees it is standard. It's perfectly ok for your backend process that consumes the data translate it into something that's easier for your frontend to deal with.

# ? Sep 10, 2018 16:32

huhu: Feb 24, 2006

Wanted to copy this over from the JavaScript thread to see if anyone here might know.

We've just started using Styled-Components and want to test them within Enzyme.

So we have a function...

code:

const CourseRating = ({ rating }) => {
    if (rating) {
        return <StyledCourseRating>{`${rating}/5`}</StyledCourseRating>
    } else {
        return <StyledCourseRating>No Rating</StyledCourseRating>
    }
}

And the StyledCourseRating comes from this Styled Component:

code:

const StyledCourseRating = styled.div``

Which they eventually get returned from this:

code:

function ResultListItem(props) {
    const {
        rating,
    } = props

    return (
        <ResultListItemWrapper>
            <CourseRating rating={rating} />
        </ResultListItemWrapper>
    )
}

Our test is ugly though with the .dive().dive(). We're still new to testing so maybe we're not even writing good unit tests but I'm also concerned about having to dive twice. Any suggestions?

code:

const componentProps = { rating: 4.5 }

const component = shallow(<ResultListItem {...componentProps} />)
describe('ResultListItem Component', () => {
        expect(
            component
                .find(CourseRating)
                .dive()
                .dive()
                .text()
        ).to.equal(`${componentProps.rating}/5`)
    })

# ? Sep 10, 2018 16:42

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

HaB posted:

So this is more of a general opinion question:

In my professional life, I am rarely called upon to both design a back-end API and code a front end for it. Make changes to an existing API? Sure, but by and large, I am considered "full stack" only in that I can work on both, but I am rarely completely responsible for both.

On my latest personal project however, I am doing everything myself, and that has raised some questions regarding overall approach. My initial pass was: back-end first. Basically: I have this data, here's some endpoints to get it out, front-end must deal with the rest. The issue is, I find I am doing entirely too much logic on my front-end - or at least what feels like too much logic.

For example I have a consolidated search which returns results from multiple sources - a local one, and some remote ones. Since the remote sources aren't mine, I don't have control over what field names appear. But as I am putting together the front-end pages, I am doing an awful lot of:
code:
if (data.source === 'LOCAL')
and it's started to feel really clunky. So last night I started refactoring the back-end to basically make all the search result items have the same shape, no matter what the source is. I am hoping this will greatly simplify both GraphQL queries as well as template logic.

So I guess my question is: assuming YOU are the one-stop-shop covering soup to nuts on a given app - what's your usual approach?

you could look at something like JSON-LD if you want to normalize different request shapes into a single format. this is only really useful if you're dealing with third party apis tho. for an endpoint you control i'd just write up some json schemas and make sure both the front end and back end share them and adhere to them

# ? Sep 10, 2018 16:47

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

rujasu posted:

I don't think MS will ever give up the browser game either, but if they did, it would surely mean shipping with Firefox or Chrome.

Now that we're firmly in sci-fi territory, I want my own starship, too.

# ? Sep 10, 2018 17:12

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

Munkeymon posted:

Anyone else think Chrome latest is rendering text taller than it was? I think I'm seeing the bottom few pixels cut off in some embedded tweets, probably as a result.

A "well akshually" from SO for proof!

# ? Sep 10, 2018 17:35

rujasu: Dec 19, 2013

Munkeymon posted:

Now that we're firmly in sci-fi territory, I want my own starship, too.

Like I said, I don't think MS will ever stop shipping their own browser, even if it ends up being something like WebKit with an MS logo.

# ? Sep 10, 2018 17:39

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

rujasu posted:

Like I said, I don't think MS will ever stop shipping their own browser, even if it ends up being something like WebKit with an MS logo.

They won't ship open source anything in Windows because they're afraid of getting sued, so they will never stop maintaining their own browser. I'm all for this because I think the competition is good and is why we have the aggressively mediocre Edge to replace the obstinately bad IE in the first place.

# ? Sep 10, 2018 18: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.

Started new job today:

+ Cool atmosphere.
+ Big impressive projects with high profile clients.
+ Going to be in charge of developing my own little angular application for which all the end points, mock ups, specs and user stories are already done.

------------- they won't pay for a loving webstorm license and are literally forcing me to use vscode because everyone else does.

(Not a dig at VSCode. VSCode is fine, I prefer webstorm.)

# ? Sep 10, 2018 22:09

my bony fealty: Oct 1, 2008

Embrace VSCode it owns

Make sure to install Prettier and have your other members do that too

# ? Sep 10, 2018 22:16

crazysim: May 23, 2004; I AM SOOOOO GAY

Will they allow you to use Live Share in VSCode? I'm seriously thinking of switching to more part time in that IDE just for that.

# ? Sep 10, 2018 22:35

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

huhu posted:

Wanted to copy this over from the JavaScript thread to see if anyone here might know.

code:

const componentProps = { rating: 4.5 }

const component = shallow(<ResultListItem {...componentProps} />)
describe('ResultListItem Component', () => {
        expect(
            component
                .find(CourseRating)
                .dive()
                .dive()
                .text()
        ).to.equal(`${componentProps.rating}/5`)
    })

Ask yourself: why am I testing the CourseRating component in my ResultListItem component test?

If you have a test for CourseRating, this test is pointless.

# ? Sep 11, 2018 02:16

huhu: Feb 24, 2006

Lumpy posted:

Ask yourself: why am I testing the CourseRating component in my ResultListItem component test?

If you have a test for CourseRating, this test is pointless.

Solid question. I'll definitely need to think on that.

# ? Sep 11, 2018 03:09

huhu: Feb 24, 2006

New question - I've got an API where I'd like to save formatted text (thinking HTML) and then send that to a React front end to be displayed as a blog. However React doesn't seem to like this, with the suggested solution being

code:

<td dangerouslySetInnerHTML={{__html: this.state.actions}} />

Is there a better/safer way to store formatted text on the backend and deliver it to React?

# ? Sep 22, 2018 15:27

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

huhu posted:

New question - I've got an API where I'd like to save formatted text (thinking HTML) and then send that to a React front end to be displayed as a blog. However React doesn't seem to like this, with the suggested solution being
code:
<td dangerouslySetInnerHTML={{__html: this.state.actions}} />
Is there a better/safer way to store formatted text on the backend and deliver it to React?

Markdown?

# ? Sep 22, 2018 16:16

my bony fealty: Oct 1, 2008

Theres a package called ReactHtmlParser that'll do it without dangerouslySetInnerHtml

Idk what it uses under the hood though

# ? Sep 22, 2018 16:21

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 17:53

smackfu: Jun 7, 2004

They are really just trying to make you think about XSS attacks with the naming.

Any other way of doing it is going to have the same code at the bottom, it just might hide it from you.

# ? Sep 22, 2018 16:22

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

«‹›235 »