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 »

Dominoes: Sep 20, 2007

Vincent Valentine posted:

Create-React-App is simply unbeatable for most single-dev spare-time non-commercial apps.

I've found it's cleaner and more flexible to simply use Webpack 4 and its dev server.

If you do anything CRA considers non-standard, it becomes a pain. Additionally, I think the specificity of having a config designed around one package is misleading; most of CRA's functionality has nothing directly to do with React.

Dominoes fucked around with this message at 16:21 on Oct 4, 2018

# ? Oct 4, 2018 05:57

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 18:34

LOOK I AM A TURTLE: May 22, 2003; "I'm actually a tortoise."; Grimey Drawer

Out of curiosity, how many of you guys using React are writing in TypeScript, or Flow, or some other static typing system? I'm not a fan of dynamically typed programming, so plain JS is a bit of a deal-breaker for me. It seems to me like TypeScript hasn't yet caught on as much in the React world as with Angular, but is it getting more traction?

# ? Oct 4, 2018 12:07

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

TypeScript is essential in my React projects. It�s so helpful, and once you get over like learning curve, it�s great.

# ? Oct 4, 2018 12:09

Dominoes: Sep 20, 2007

# ? Oct 4, 2018 16:15

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

geeves posted:

I don't know how Angular is these days, but at least AngularJS vs React - React was more simplistic and pretty much a view upon which you could build with other tools once you needed them.

AngularJS was here's 7 different ways of doing the same thing - have fun. Then back tracking and saying to use Directives or BindToController because that's the proper way. When Google then just abandoned the product then stupidly kept using Angular to much confusion just screams that it's a poorer product. (It might not be, but drat you'd think they'd be smarter about branding because it is important)

I'm still a little startled at how badly the branding thing went for Google/Angular.

Angular is far enough removed from AngularJS they should have just called it something different entirely. It was downright stupid that they did not.

So just to chime in on the other side of the argument: I greatly dislike React* and really like Angular (NOT AngularJS). I worked with AJS for years, and it was fine at the time, but Angular is so much better now it doesn't even make sense for them to share a name, since they share very little else.

Angular's generator tools are fairly close to Rails' tools at this point. An entire new app with all the scaffolding you need is just a few keystrokes away, as is adding new components/services/controllers, etc. I mention it since someone was touting the power of create-react-app or whatever their generator is called. For Angular, Typescript is built-in from the word jump, not an option you have to configure somewhere.

The chief difference, which is perhaps the one other thing which remains held over from AJS is: if you want to do EVERYTHING in one framework, use Angular. React is really just the View part of MVC, so it offers plenty of choices for the M and C parts. Angular is also tied pretty heavily to RxJS, if you're a fan of it (and you should be - it's great). So every freakin thing is an Observable or can be converted to one.

All THAT being said. I now mostly do Vue at work, and I love it. It's like someone took all the good things from React AND Angular and greatly simplified all of it and that's Vue. I like it so much I have converted a large-ish personal project I already had in progress to Vue, and it's so much cleaner and simpler than the Angular version was.

Vincent Valentine posted:

I personally prefer React simply because it's tools and support are so great. I started looking at React from AngularJS a couple of years ago and going from Angular Dev Tools to React Dev Tools sold me on the entire framework. Create-React-App is simply unbeatable for most single-dev spare-time non-commercial apps.

Against AngularJS's tools - I agree. Against Angular's? Not at all. I'm not a Rails fan by any stretch, but do some of it because I am paid to, but the toolchain is kind of impressive, even if you don't like the rest of Rails/Ruby. Angular's toolchain is basically modeled off of Rails', and it's drat good.

So my answer to FateFree's question:

Again - depends on what you want. If you want an all in one solution: Angular is pretty unbeatable at this point because it's just about the only game in town for that. If instead you want more control over the individual parts of your M V and C, then Vue or React will probably suit you just fine. I personally prefer Vue by a million. Vue's devtools are already nice and it even has a greatly simplified version of the Store concept in VueX.

*I mostly hate React for reasons people have said they like it: I WANT a template and logic related to the template IN the template. JSX is an abomination unto the Lord and just complicates poo poo which should be simple and IS simple in literally anything but React. And since Redux and React tend to travel hand in hand - I pretty much hate Redux too. WAY too much boilerplate to toggle a single value somewhere. Dogma is anathema to me in general so React/Redux's dogmatic devotion to "ONE WAY DATA FLOW IS THE TRUE WAY" is really off-putting to me. Sometimes two-way binding is just fine.

# ? Oct 4, 2018 16:46

Dominoes: Sep 20, 2007

HaB posted:

For Angular, Typescript is built-in from the word jump, not an option you have to configure somewhere.

It's not that bad. I think this (and other trouble in the JS community) stems from a difficulty finding good tutorials and documentation, in a sea of poor and obsolete ones.

package.json:

JSON code:

{
  // Name, license etc
  "dependencies": {
    "react": "^16.4.1",
    "react-dom": "^16.4.1"
  },
  "scripts": {
    "serve": "webpack-dev-server",
  },
  "devDependencies": {
    "@types/react": "^16.4.6",
    "@types/react-dom": "^16.0.5",
    "ts-loader": "^4.4.2",
    "typescript": "^2.8.3",
    "webpack": "^4.15.1",
    "webpack-cli": "^3.0.8",
    "webpack-dev-server": "^3.1.4"
  }
}

webpack.config.js:

JavaScript code:

const path = require('path');

module.exports = {
    entry: path.join(__dirname, '/src/main.tsx'),
    output: {
        filename: 'build/main.js',
        path: __dirname
    },
    module: {
        rules: [
            {
                test: /\.tsx?$/,
                loader: 'ts-loader',
                exclude: /node_modules/,
            },
        ],

    },
    resolve: {
        extensions: [".tsx", ".ts", ".js", ".wasm"]
    },
    mode: "development"
};

Dominoes fucked around with this message at 17:17 on Oct 4, 2018

# ? Oct 4, 2018 17:14

Doom Mathematic: Sep 2, 2008

Alright so I have a potentially dumb question. I have (for the sake of argument) a simple React component containing a single text field. There's an incoming prop which gives the text field's value. Say its value is "A" right now. So when the DOM node renders, it has its own value property, which is initially populated with a value "A", but is a separate value from the prop. There's a second incoming prop, which is an onChange handler.

Now the user types, so it says "AB" instead. At this point, the incoming prop says "A" while the DOM element's value is "AB". The two disagree with one another. But luckily we call onChange("AB"), which goes up to the parent component, causes its state to change, causes a new prop with value "AB" to be sent down, and the prop and the DOM element continue to agree. So far so good.

Here's my problem: the onChange("AB") call is not synchronous. For unavoidable reasons, there is a small interval between onChange("AB") being called and the new prop value "AB" arriving. During this interval, let's say the user continues typing, so the DOM element value becomes "ABC". This causes onChange("ABC") to be called. After a short while, the prop updates to "AB". Since the prop is the source of truth, this causes the text field to clobber the "ABC" which the user just typed. It now says "AB" again.

This causes all kinds of problems. For example, if the user doesn't notice and continues typing, we get "ABD" when we should have "ABCD".

So how do I prevent this? I feel like the solution is to introduce some local state to the inner commponent, a third location where the value is stored, which can be updated synchronously. But by itself that doesn't avoid the problem of updates being sent up to the parent component and then returning "late".

# ? Oct 4, 2018 21:56

The Fool: Oct 16, 2003

Why do you need to change a text box while a user is typing in it?

# ? Oct 4, 2018 22:00

Doom Mathematic: Sep 2, 2008

The Fool posted:

Why do you need to change a text box while a user is typing in it?

Well, I'm using "a text box" as a shorthand for a more complicated component which would make the issue harder to demonstrate.

But also: if the incoming prop changes, then the value in the text box changes. That's what happens if you put <input type="text" value={this.props.value} onChange={this.props.onChange} />, right? The prop is the source of truth. Is there a sensible way to selectively disregard the changed prop so that this works?

# ? Oct 4, 2018 22:09

The Fool: Oct 16, 2003

I feel like changing a users input while they are typing is a bad user experience regardless.

However, it's possible that debouncing may help you.

# ? Oct 4, 2018 22:28

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

Doom Mathematic posted:

Alright so I have a potentially dumb question. I have (for the sake of argument) a simple React component containing a single text field. There's an incoming prop which gives the text field's value. Say its value is "A" right now. So when the DOM node renders, it has its own value property, which is initially populated with a value "A", but is a separate value from the prop. There's a second incoming prop, which is an onChange handler.

Now the user types, so it says "AB" instead. At this point, the incoming prop says "A" while the DOM element's value is "AB". The two disagree with one another. But luckily we call onChange("AB"), which goes up to the parent component, causes its state to change, causes a new prop with value "AB" to be sent down, and the prop and the DOM element continue to agree. So far so good.

Here's my problem: the onChange("AB") call is not synchronous. For unavoidable reasons, there is a small interval between onChange("AB") being called and the new prop value "AB" arriving. During this interval, let's say the user continues typing, so the DOM element value becomes "ABC". This causes onChange("ABC") to be called. After a short while, the prop updates to "AB". Since the prop is the source of truth, this causes the text field to clobber the "ABC" which the user just typed. It now says "AB" again.

This causes all kinds of problems. For example, if the user doesn't notice and continues typing, we get "ABD" when we should have "ABCD".

So how do I prevent this? I feel like the solution is to introduce some local state to the inner commponent, a third location where the value is stored, which can be updated synchronously. But by itself that doesn't avoid the problem of updates being sent up to the parent component and then returning "late".

Your real problem is this:

code:

 For unavoidable reasons, there is a small interval between onChange("AB") being called and the new prop value "AB" arriving.

But you can mitigate this in a couple ways, assuming that it's your code calling some long-running or remote code on each keystroke that is the source of the delay:

1. If no other part of the app needs to know about the value of the text box until submit, you can make it an "uncontrolled" form input and pass it a defaultValue instead of a value. Then your onChange can update local state if you want, or just not handle change at all if you don't need it. You can then pull the value out on submit either from local state if you were updating on change or blur, or via a ref if you weren't.

2. Your onChange can block input until whatever thing you are calling that is forcing the delay returns by setting disabled or whatever. This is a really crappy user experience though.

3. You have a "fake" controlled input that captures keys from the user and adds them to a queue and you send things in the queue (maybe batched or joined) to whatever function that is causing the delay and the return goes to a hidden input that is the "real" one.

But the real answer is "don't have code that runs so long on each keystroke".

Lumpy fucked around with this message at 23:00 on Oct 4, 2018

# ? Oct 4, 2018 22:54

Analytic Engine: May 18, 2009; not the analytical engine

Doesn't this work for you? I was using it recently for simple form stuff and it was sooo much clearer than the Angular 1.x way.

https://reactjs.org/docs/forms.html

# ? Oct 5, 2018 02:52

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

Does anyone have experience working with webpack hooks? I�m having an issue where I�m defining a variable outside of wepack scope, it gets altered by a babel transformer, but then by the time i console log it after the webpack hook has run, it�s undefined because webpack is not aware of it�s existence.

I can post examples tomorrow

# ? Oct 5, 2018 09:15

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

Doom Mathematic posted:

Alright so I have a potentially dumb question. I have (for the sake of argument) a simple React component containing a single text field. There's an incoming prop which gives the text field's value. Say its value is "A" right now. So when the DOM node renders, it has its own value property, which is initially populated with a value "A", but is a separate value from the prop. There's a second incoming prop, which is an onChange handler.

Now the user types, so it says "AB" instead. At this point, the incoming prop says "A" while the DOM element's value is "AB". The two disagree with one another. But luckily we call onChange("AB"), which goes up to the parent component, causes its state to change, causes a new prop with value "AB" to be sent down, and the prop and the DOM element continue to agree. So far so good.

Here's my problem: the onChange("AB") call is not synchronous. For unavoidable reasons, there is a small interval between onChange("AB") being called and the new prop value "AB" arriving. During this interval, let's say the user continues typing, so the DOM element value becomes "ABC". This causes onChange("ABC") to be called. After a short while, the prop updates to "AB". Since the prop is the source of truth, this causes the text field to clobber the "ABC" which the user just typed. It now says "AB" again.

This causes all kinds of problems. For example, if the user doesn't notice and continues typing, we get "ABD" when we should have "ABCD".

So how do I prevent this? I feel like the solution is to introduce some local state to the inner commponent, a third location where the value is stored, which can be updated synchronously. But by itself that doesn't avoid the problem of updates being sent up to the parent component and then returning "late".

So I'm assuming you're doing something like running a search and fetching new results from a remote endpoint, or updating the value of something on a server when the user changes the input. In situations like this I almost always use local state in the inner component and also debounce the actual onChange function. That way the component updates quickly, and you also don't make a remote call for every single keystroke. I know it might feel silly to keep the value in two places, but that's not really what you're doing. The incoming prop contains the last value that was sent to the server, while the local state contains the current value. Obviously they'll sync up when the user stops typing, but it's that lag time in between that makes them actually separate things.

# ? Oct 13, 2018 18:32

Honest Thief: Jan 11, 2009

LOOK I AM A TURTLE posted:

Out of curiosity, how many of you guys using React are writing in TypeScript, or Flow, or some other static typing system? I'm not a fan of dynamically typed programming, so plain JS is a bit of a deal-breaker for me. It seems to me like TypeScript hasn't yet caught on as much in the React world as with Angular, but is it getting more traction?

I go with flow or plain proptypes, I never cared much for TS, despite its benefits, I always saw the reasoning to implementing it on a project being something akin to static types meaning less bugs, which always strikes me as wrong or at least misguided.
Plus, I just like JS better.

# ? Oct 15, 2018 14:43

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

typescript is probably the only piece of anything in this stupid ecosystem that actually works

i've spent more time just yesterday fighting with webpack and parcel than i've ever spent fighting typescript.

# ? Oct 15, 2018 18:53

Doom Mathematic: Sep 2, 2008

Thank you to everybody who suggested debouncing as the solution to my problem, it seems to be working.

# ? Oct 16, 2018 21:21

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

Has anyone used bacon js or kefir for streams and are really opinionated about either?

I�m looking into Kefir now, and at first glance, I like the docs and the ease of use compared to rxjs

# ? Oct 17, 2018 14:38

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

I use Typescript + React and I would not start a new project without it.

# ? Oct 18, 2018 01:03

General Emergency: Apr 2, 2009; Can we talk?

What would be good resources on best practices for unit testing front end javascript? Specifically I'm right now using React and Jest but a bit lost on what I want to test and in what way...

# ? Oct 19, 2018 08:19

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

General Emergency posted:

What would be good resources on best practices for unit testing front end javascript? Specifically I'm right now using React and Jest but a bit lost on what I want to test and in what way...

Also interested in this because I have the same problem

# ? Oct 19, 2018 08:27

smackfu: Jun 7, 2004

I find 100% code coverage checks useful for React since it�s pretty easy to get to and lets you know if you missed a callback or something.

You should always review snapshot changes before committing them, otherwise they are not doing anything for you.

# ? Oct 19, 2018 11:06

Honest Thief: Jan 11, 2009

I'd avoid relying a lot on snapshots, they can become a chore during development, and always running npm test -- -u which defeats the purpose of testing

# ? Oct 19, 2018 18:36

my bony fealty: Oct 1, 2008

Kent C Dodds just released his big course at testingjavascript.com and he's p much the JS testing guru so if yr willing to throw down the $ I'm sure it's worth it

# ? Oct 19, 2018 19:42

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

Snapshots are useless and generally I have unit tests surrounding basic components verifying they work, and then i just unit test rendering the other components by shallow rendering and asserting that no error is thrown. Maybe more deep tests are useful with really complex UI, but I find that spending time on unit tests on business logic (in my redux action creators and thunks) is a better use of my time than creating elaborate and exhaustive assertions about UI components. This also obviously only works if you've taken care to separate business logic from your UI, which you should be doing anyway.

# ? Oct 19, 2018 23:42

Mahatma Goonsay: Jun 6, 2007; Yum

My experience with using snapshots is that you have to look at the output to make sure that what you think is going to be there is actually there.

# ? Oct 20, 2018 03:17

my bony fealty: Oct 1, 2008

This React hooks thing that just got announced is dope. Played around with it today and I am stoked to never write a class component again. The api for managing state feels so nice and intuitive.

# ? Oct 27, 2018 03:24

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

I am rock hard for react hooks, sad it's only in alpha still. Going to upgrade to 16.6.0 tomorrow and start suspensifying parts of my app.

# ? Oct 29, 2018 04:06

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

prom candy posted:

I am rock hard for react hooks, sad it's only in alpha still. Going to upgrade to 16.6.0 tomorrow and start suspensifying parts of my app.

My bigass app is still React 15.x :smith:

"Upgrade to 16" is that thing at the bottom of the backlog that keeps getting buried by the endless new stuff.

# ? Oct 29, 2018 15:07

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

Lumpy posted:

My bigass app is still React 15.x "Upgrade to 16" is that thing at the bottom of the backlog that keeps getting buried by the endless new stuff.

React codemods are your friend.

# ? Oct 29, 2018 15:13

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

Chenghiz posted:

React codemods are your friend.

yeah, and I'm fairly sure things will work fine if I upgrade, it's just that there are only so many hours in the day, and I'm the entire design / front end / marketing / QA / IT / team.

# ? Oct 29, 2018 15:32

reversefungi: Nov 27, 2003; Master of the high hat!

Does anyone have recommendations for a grid system similar to Bootstrap in React? I know there's Reactstrap/React-bootstrap, but we'd like to avoid pulling in the entire library for just a fraction of the features. And we can't use CSS grid because we have to support IE9 (I know, I know...). I'm sure there are some good pre-existing solutions out there, was wondering if anyone had some good personal experiences with any library that they'd recommend.

# ? Oct 29, 2018 19:44

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

Do you need it to be "for React?" Can you just include a CSS file and use the classnames?

Also my real advice is if you're working somewhere where you have to support IE9 you should quit.

# ? Oct 29, 2018 21:44

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

prom candy posted:

Do you need it to be "for React?" Can you just include a CSS file and use the classnames?

Also my real advice is if you're working somewhere where you have to support IE9 you should quit.

This also goes for IE11 imo. So much exciting poo poo you just can't do

# ? Oct 29, 2018 21:50

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

Has anyone used React.Suspense yet for data fetching?

I only briefly taken a look and am not sure how exactly it would work or if it would work

# ? Oct 29, 2018 23:17

Gildiss: Aug 24, 2010; Grimey Drawer

The Dark Wind posted:

Does anyone have recommendations for a grid system similar to Bootstrap in React? I know there's Reactstrap/React-bootstrap, but we'd like to avoid pulling in the entire library for just a fraction of the features. And we can't use CSS grid because we have to support IE9 (I know, I know...). I'm sure there are some good pre-existing solutions out there, was wondering if anyone had some good personal experiences with any library that they'd recommend.

Ive been using react-md.

# ? Oct 29, 2018 23:39

my bony fealty: Oct 1, 2008

Joda posted:

This also goes for IE11 imo. So much exciting poo poo you just can't do

Not using modern features and best practices because someone in charge thinks you need to support a browser that has less than one percent usage, and has been disowned by its creator, should be illegal

Second just using a CSS file

# ? Oct 30, 2018 00:15

Vincent Valentine: Feb 28, 2006; Murdertime

Grump posted:

Has anyone used React.Suspense yet for data fetching?

I only briefly taken a look and am not sure how exactly it would work or if it would work

Dumbed down version because I've only used it briefly and don't have deep knowledge myself, but to put it in redux terms:

You create a cache, this is essentially a store.

You make a createResource(called Resource going forward), which I hope I am using correctly but for me it's just a api fetch call that returns a promise. The data from that promise goes to the cache.

You import and call Resource.read() in your main component, which is basically map state to props from redux. If the resource has not already put it's data in the cache, it does so now.

From there, you can call whatever variable you assigned the result of resource.read to in order to access the information from the response json(or whatever you returned from the fetch promise).

Suspense is really, really good. I'm still getting the hang of how it works under the hood (it throws the promise, which was weird at first but I think I get why now), but is something that's definitely worth learning more about.

# ? Oct 30, 2018 02:41

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

The Important React People are all saying that data fetching with suspense and react-cache is still alpha and probably not ready for prime time.

Do you guys have any preferences for code splitting in React? I was going to lazy load all the top level screens in my SPA but there's a ton of component sharing going on. Does that duplicate code in the different chunks and increase the overall download size?

# ? Oct 30, 2018 03:48

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 18:34

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

prom candy posted:

The Important React People are all saying that data fetching with suspense and react-cache is still alpha and probably not ready for prime time.

That's what I thought was the case. I guess it's safe to say we should probably wait to use this new logic for data fetching until the concurrent suspense releases, assuming react-cache will release at the same time.

Also new version of CRA is released with TypeScript support! YAY

But they also force you to use relative path imports........WHAT!?!

Automated change by running yarn start

# ? Oct 30, 2018 13:55

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

«‹›235 »