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 »

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

Ape Fist posted:

Sorry I meant to template, woops.

So what I wrote in React wouldn't work then?

(at this point I'm not looking for the most efficient representation, just a comparative one.)

It would, it's just very verbose. Using a class based component (which you did) is generally for when you need lifecycle methods (componentDidMount, componentDidUpdate, etc) or your component needs to manage some state that only it needs to know about. My example is a stateless functional component, which you use if your component does not need to manage any state itself. I find a great majority of the components I write are stateless. So for Apples to Apples (or as close as you can get) comparison, then yes, your class based component will render "3" (once you fix the bug in your function call =) . That said, it's not very "React-like" to do it that way.

You also need to extend class React.Component

So:

JavaScript code:

class App extends React.Component {
  // if these don't change, no need to hold them in state
  numOne = 1;
  numTwo = 2;

  render() {
    return <div>{ this.numOne + this.numTwo }</div>
  }
}
export default App

\/\/ You got it then.

Lumpy fucked around with this message at 21:14 on Jul 31, 2018

# ? Jul 31, 2018 21:06

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 23:22

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 yeah there's no need for that +.

I'm just seeing if my mental model is compatible with React, coming from Angular the Angular component I wrote is also overly verbose as well but it's just a small excercise.

# ? Jul 31, 2018 21:10

my bony fealty: Oct 1, 2008

You will be fine with React. It's got a small API and you'll find organization and component patterns you like quickly.

Just study up on component lifecycle hooks, when you'd want to use a stateful vs stateless component, and state management and you'll be set. Once you feel ok about that start looking into higher order components and/or render props. Routing too.

You'll want to look at Redux or Mobx or some state management tool at some point, but setState should be good enough for a while.

There are likely thousands of free React tutorials out there, and $10 Udemy courses that go pretty in-depth.

# ? Jul 31, 2018 22:52

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.

Ahh I use @NGRX/Store for Angular anyway which is basically Redux so~

Props are Child<->Parent component communication, routing is routing is routing. Conceptually it's all fine.

No services is a bit of a downer though. But at least React plays nicely with RXJS apparently. I might install the Typescript module too.

Ape Fist fucked around with this message at 23:18 on Jul 31, 2018

# ? Jul 31, 2018 23:16

Vincent Valentine: Feb 28, 2006; Murdertime

my bony fealty posted:

You will be fine with React. It's got a small API and you'll find organization and component patterns you like quickly.

Just study up on component lifecycle hooks, when you'd want to use a stateful vs stateless component, and state management and you'll be set. Once you feel ok about that start looking into higher order components and/or render props. Routing too.

You'll want to look at Redux or Mobx or some state management tool at some point, but setState should be good enough for a while.

There are likely thousands of free React tutorials out there, and $10 Udemy courses that go pretty in-depth.

Speaking of stateless components, did they ever actually get around to optimizing them?

Back in 2015(references: https://twitter.com/dan_abramov/status/755343583004286976 and https://reactjs.org/blog/2015/10/07/react-v0.14.html#stateless-functional-components ) it was explained that, for all intents and purposes, a stateless component is identical to a stateful component since they were wrapped in the same class. The React team mentioned that these components would eventually become actually optimized and would lose all of the bulk that makes them slower.

Problem was, this issue was never well documented in the first place. It was never a part of the react documentation, only that patch note and tweet. So, the fact that the current docs imply that stateless components are not wrapped in the same class as regular components doesn't actually help since it always stated that. I've looked for a patch note or similar tweet that says "We finally did the thing where we make stateless components faster", but no dice.

I have an issue with stateless components in that they always re-render since they don't have access to shouldComponentUpdate. I found myself getting performance gains by just making all my Stateless components into PureComponents, which has a ShouldComponentUpdate lifecycle always active by default with no work needed. There are of course places where a pure component isn't the correct sure, but in most cases it seemed to be a good swap.

Has there been a benchmark done on these different styles of components to see what the actual performance gains are in react 16?

edit: why the hell is it embedding that giant tweet when did that start happening

Vincent Valentine fucked around with this message at 01:02 on Aug 1, 2018

# ? Aug 1, 2018 00:58

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

Vincent Valentine posted:

stuff

You should tweet Dan and ask him. He's a nice and accessible guy.

# ? Aug 1, 2018 01:02

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

I have a number of Angular apps, with a structure like this:

code:

angular
-foo
--src
---main.ts
---app
----components
--angular.json
--package.json
-bar
--src
---main.ts
---app
----components
--angular.json
--package.json
-baz
--src
---main.ts
---app
----components
--angular.json
--package.json

then any time I want to build, I just navigate to /foo or /bar or /baz and ng build.

But now our apps our getting to where we want to be able to share services/components across them.

I tried pointing to a component in /baz from /bar with a bunch of ../../ to navigate up, but it didn't like that, ultimately complaining: Cannot redeclare block-scoped variable 'ngDevMode'.

The Angular Style Guide seem to be saying I should restructure everything and have it all under a single /app folder like:

code:

angular
-src
--main.ts
--app
---foo
----components
---bar
----components
---baz
----components
-angular.json
-package.json

but wouldn't doing so make it monolithic and then I couldn't build each app separately? So any change to foo would mean I'd have to essentially rebuild bar and baz too?

# ? Aug 1, 2018 14:31

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

Vincent Valentine posted:

Speaking of stateless components, did they ever actually get around to optimizing them?

Back in 2015(references: https://twitter.com/dan_abramov/status/755343583004286976 and https://reactjs.org/blog/2015/10/07/react-v0.14.html#stateless-functional-components ) it was explained that, for all intents and purposes, a stateless component is identical to a stateful component since they were wrapped in the same class. The React team mentioned that these components would eventually become actually optimized and would lose all of the bulk that makes them slower.

Problem was, this issue was never well documented in the first place. It was never a part of the react documentation, only that patch note and tweet. So, the fact that the current docs imply that stateless components are not wrapped in the same class as regular components doesn't actually help since it always stated that. I've looked for a patch note or similar tweet that says "We finally did the thing where we make stateless components faster", but no dice.

I have an issue with stateless components in that they always re-render since they don't have access to shouldComponentUpdate. I found myself getting performance gains by just making all my Stateless components into PureComponents, which has a ShouldComponentUpdate lifecycle always active by default with no work needed. There are of course places where a pure component isn't the correct sure, but in most cases it seemed to be a good swap.

Has there been a benchmark done on these different styles of components to see what the actual performance gains are in react 16?

edit: why the hell is it embedding that giant tweet when did that start happening

Functional components are faster in React 16 than in 15, but as of last year, Dan was saying to still use PureComponent instead. See this twitter thread thing (click to read where Dan chimes in):

https://twitter.com/trueadm/status/916706152976707584

I also came across this, which seems interesting: https://medium.com/missive-app/45-faster-react-functional-components-now-3509a668e69f

# ? Aug 1, 2018 15:12

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

k so - have a thing I am looking for a good approach to take with.

I have some 71 icons I need to use in my app. They are in svg format so they can be styled and resized as needed. They are only all ever used in one place: the signup path, because the user has to select one which then becomes their avatar. The avatar gets used elsewhere in the app. Eventually, the app will have some social functions, such as user profiles and messaging, which would mean needing to load other user's avatars, but right now it does not - only the one the currently logged in user picks.

In total, the path data for all of them comes to roughly 1.4mb total.

Option 1: My initial implementation was to just basically stick them on the bottom of the index.html page in a hidden element and reference them by id when I need one.
Pros: easy to grab since all you need is a string for the id, meaning when social features eventually get added, it's trivial to pull ANY user's avatar
Cons: swells the index page a good bit, but I mean - is 1.4 mb a lot these days?

Option 2: Make them Vue components, and store the symbol for the Avatar in user storage, or session storage.
Pros: does NOT swell the index page, and I have seen a few solutions for lazy loading components
Cons: plenty of tedious copy/paste work to make them components

Option 3: Stick them on the bottom of the signup page, since that's the only place they are all used, store the avatar pick in session, and create an avatar component which loads based on the avatar pick
Pros: solves the index problem
Cons: will have to be refactored once I eventually DO add social features

Option 4: ????

I'm open to suggestions here.

Shoot me some ideas, or some thoughts on the above ideas.

# ? Aug 2, 2018 01:05

Mr Shiny Pants: Nov 12, 2012

Create one big picture with all the icons in it, overlay a table on it with cells spaced so the cell encapsulates the icon, put an index on the cell and a eventlistener on it so you can catch which icon the user clicks.

I don't know if this works. I thought it was fun to think about.

1,4 MB is not that big anyway.

# ? Aug 2, 2018 09:42

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

Mr Shiny Pants posted:

Create one big picture with all the icons in it, overlay a table on it with cells spaced so the cell encapsulates the icon, put an index on the cell and a eventlistener on it so you can catch which icon the user clicks.

I don't know if this works. I thought it was fun to think about.

1,4 MB is not that big anyway.

Well the UI is setup so the icon names appear in a spinner box, which the user can cycle through, changing the displayed icon one at a time. I like the interface I have for now.

I'm starting to think 1.4 megs isn't that big of a deal anyway. It's an SPA, so if it's on the index it will only load once, so I may just go ahead with that.

# ? Aug 2, 2018 12:27

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

The user has to click up to 71 times to find an icon they like?

# ? Aug 2, 2018 12:30

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

Thermopyle posted:

The user has to click up to 71 times to find an icon they like?

Actually it's 50. It uses a subset.

Basically this is how usernames are chosen on the site:

There's a spin box for Colors (6)
Another spin box for Animals(50)
and a 4 digit random code, which can be re-randomized.

So you pick one of each, and get a user name like: OrangeAardvark7756

Luckily the animal icons are so well designed (by a goon, no less) and cute that people WANT to click through all of them, just to see them.

# ? Aug 2, 2018 12:58

abraham linksys: Sep 6, 2010

what's your build pipeline like? if you're importing these SVGs through like Webpack, it should be relatively easy to split them out to a chunk that gets lazy-loaded. I haven't used that stuff much but I think you could do something like import() to basically grab every file matching a given regex, so you can e.g. load all the SVGs in a specific folder

alternatively, if they're already reasonably optimized, just leaving them as static files that don't go through your build pipeline and referencing the urls directly seems fine?

# ? Aug 2, 2018 14:57

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

Why can�t you reference them as images and host them separately? It seems crazy to me to bundle them into your app at all.

# ? Aug 2, 2018 15:27

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

Mr Shiny Pants posted:

I don't know if this works. I thought it was fun to think about.

1,4 MB is not that big anyway.

The modern web, ladies and gentlemen.

# ? Aug 2, 2018 16:50

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

Suspicious Dish posted:

The modern web, ladies and gentlemen.

1.4M of... SVGs :monocle:

# ? Aug 2, 2018 17:09

A Big... Dog: Mar 25, 2013; HELLO DAD

Lumpy posted:

1.4M of... SVGs

IMPOSSIBLE

# ? Aug 2, 2018 17:51

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

Chenghiz posted:

Why can�t you reference them as images and host them separately? It seems crazy to me to bundle them into your app at all.

The whole point of them being svgs is that they can be resized and styled on the fly. Referencing them as images defeats that purpose.

# ? Aug 2, 2018 17:52

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

HaB posted:

The whole point of them being svgs is that they can be resized and styled on the fly. Referencing them as images defeats that purpose.

...Can't you use a regular <img> tag and manipulate its height/width/colors/etc... like usual? The SVG should adapt as expected and the otherwise static assets can be served from a web server without bundling them into the app itself :confused:

IAmKale fucked around with this message at 18:27 on Aug 2, 2018

# ? Aug 2, 2018 18:23

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

A Big... Dog posted:

IMPOSSIBLE

The largest SVG in our app is 1.2k (a fairly complex thing that's animated with 600 bytes of css). Those must be some seriously fancy icons!

# ? Aug 2, 2018 19:25

abraham linksys: Sep 6, 2010

IAmKale posted:

...Can't you use a regular <img> tag and manipulate its height/width/colors/etc... like usual? The SVG should adapt as expected and the otherwise static assets can be served from a web server without bundling them into the app itself

fwiw if https://svgontheweb.com/ is to be believed, you actually can't (which i knew for background-image but not for an actual <img>). you sorta can for <object> but it requires injecting a stylesheet into the content I guess?

for inline, if you're using webpack, you can still lazy-load individual chunks for svgs with either svg-sprite-loader (which does fancy deduplication stuff) or just raw-loader (which doesn't). i thought you could use import() for this, but that doesn't actually support the use case of "iterate over all files in a directory" (though it would work if you had an explicit list of icon names). you can instead use the older, but afaik not deprecated, require.context() API

I was bored so I put together a demo showing this here https://glitch.com/edit/#!/webpack-folder-load. it uses webpack's raw-loader, so each raw svg gets turned into a lil JS chunk that just wraps the SVG content. you can iterate over the list of items in the folder with the requireContext.keys() API, which is what's used to show the buttons, but each chunk isn't loaded until the button is clicked and `await requireContext(key)` is called.

# ? Aug 2, 2018 19:43

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

abraham linksys posted:

fwiw if https://svgontheweb.com/ is to be believed, you actually can't (which i knew for background-image but not for an actual <img>). you sorta can for <object> but it requires injecting a stylesheet into the content I guess?

for inline, if you're using webpack, you can still lazy-load individual chunks for svgs with either svg-sprite-loader (which does fancy deduplication stuff) or just raw-loader (which doesn't). i thought you could use import() for this, but that doesn't actually support the use case of "iterate over all files in a directory" (though it would work if you had an explicit list of icon names). you can instead use the older, but afaik not deprecated, require.context() API

I was bored so I put together a demo showing this here https://glitch.com/edit/#!/webpack-folder-load. it uses webpack's raw-loader, so each raw svg gets turned into a lil JS chunk that just wraps the SVG content. you can iterate over the list of items in the folder with the requireContext.keys() API, which is what's used to show the buttons, but each chunk isn't loaded until the button is clicked and `await requireContext(key)` is called.

Yeah that little demo looks like something I can turn into something which might work for my needs. Appreciate the hand.

# ? Aug 3, 2018 00:21

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

Any thoughts on how to choose a big jesus front-end framework for my vue-cli project? Quasar, Vuetify, Framework7, onsen-ui, etc etc etc. All seem to do the same thing, all have nice looking demo pages / whatever.

My project lives in the browser for the immediate future, but being able to package as a mobile and / or electron app in the future would be a plus.

Any thoughts on why so many of these large projects are being maintained / developed concurrently?

# ? Aug 3, 2018 13:08

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

Newf posted:

Any thoughts on how to choose a big jesus front-end framework for my vue-cli project? Quasar, Vuetify, Framework7, onsen-ui, etc etc etc. All seem to do the same thing, all have nice looking demo pages / whatever.

My project lives in the browser for the immediate future, but being able to package as a mobile and / or electron app in the future would be a plus.

Any thoughts on why so many of these large projects are being maintained / developed concurrently?

Because they all suck and everyone thinks that theirs will be the one that doesn't.

I am only partially kidding.

# ? Aug 3, 2018 14:56

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

Maybe to put less cynically: big frameworks have to answer a lot of questions, can't answer them all, and people have different needs and opinions about what questions to answer and how to answer them.

# ? Aug 3, 2018 15:07

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

dupersaurus posted:

Maybe to put less cynically: big frameworks have to answer a lot of questions, can't answer them all, and people have different needs and opinions about what questions to answer and how to answer them.

This.

Not really a way to recommend one to you. You should just try them and see how they answer your questions.

I am converting a project from ng4 to Vue and doing everything by hand to learn Vue better, but I am used to Angular doing EVERYTHING, so I have been learning to get my head around bringing in a plugin/mixin to do some things. (Form validation, for example).

But thus far I haven't felt a need to adopt one of the bigger Vue bolt-on frameworks.

# ? Aug 3, 2018 16:02

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

HaB posted:

Not really a way to recommend one to you. You should just try them and see how they answer your questions.

I feel like this is the obvious truth, but the time investment is steep. I've just spent four or five hours rebuilding a number of my components after installing vue-cli-plugin-vuetify. Things seem to be going well, but the nagging doubts remain with respect to the roads not taken.

That said, I can't really stomach taking this much time to try out half a dozen alternatives.

# ? Aug 3, 2018 16:26

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

Newf posted:

I feel like this is the obvious truth, but the time investment is steep. I've just spent four or five hours rebuilding a number of my components after installing vue-cli-plugin-vuetify. Things seem to be going well, but the nagging doubts remain with respect to the roads not taken.

That said, I can't really stomach taking this much time to try out half a dozen alternatives.

Picking a big framework of any sort really takes weeks.

And you still don't always get it right.

# ? Aug 3, 2018 17:44

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

all frameworks suck and youre never gonna be happy with your decision death waits for us all hth

# ? Aug 4, 2018 05:24

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

Thermopyle posted:

Picking a big framework of any sort really takes weeks.

And you still don't always get it right.

Suspicious Dish posted:

all frameworks suck and youre never gonna be happy with your decision death waits for us all hth

These are surprisingly helpful. I don't have weeks - out of the question - this is a side project, my full time job is not software anymore, and there's a baby on the way besides.

So the procedure is to throw a dart, have attractive buttons and sliders, keep my blinders on wrt missed alternatives, be unhappy. I can live with it.

# ? Aug 4, 2018 13:25

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

Suspicious Dish posted:

all frameworks suck and youre never gonna be happy with your decision death waits for us all hth

Yeah, this is the truth.

One reason is this: You're picking constraints when you pick a framework. Different frameworks have different constraints. Constraints are good! But, unless your project is super-simple, you're never going to find a framework that has picked the constraints that perfectly match what you're doing, so you're going to have friction where the framework is limiting you in some way.

# ? Aug 4, 2018 15:31

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

Managed to get things working, using Abraham Linksys's demo as a leaping off point. Here's a lovely phone video of it:

Clicky

k no idea why that's not working.

# ? Aug 4, 2018 19:23

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 used to do a lot of poo poo manually inside of Angular only because I didn't know how to correctly use a lot of the built in stuff, heh.

# ? Aug 4, 2018 22:22

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

Anyone using CSS Modules in a prod app? I'm unsure of how to go about handling sitewide styles.

For example, every h1 element on the site should have a set font size, how would I go about implementing that in a React app? Adding an h1 rule that composes a base h1 rule from another file for every component that includes on seems tedious, and importing a base css file into the App component seems to defeat the purpose of CSS Modules.

# ? Aug 6, 2018 17:32

Honest Thief: Jan 11, 2009

Anyone has a decent workflow for working with svg animations that they can share?
I need to make some svg animations handed down by the designers and I get the idea, and how svgs work, but I can't draw one for the life of me, so animating them and experimenting can get tricky.

ddiddles posted:

Anyone using CSS Modules in a prod app? I'm unsure of how to go about handling sitewide styles.

For example, every h1 element on the site should have a set font size, how would I go about implementing that in a React app? Adding an h1 rule that composes a base h1 rule from another file for every component that includes on seems tedious, and importing a base css file into the App component seems to defeat the purpose of CSS Modules.

If what I'm getting what you're saying, I guess ideally the h1 element would be a shared component that handled the default styles on its own. Otherwise, something with the :global keyword?

# ? Aug 6, 2018 17:56

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

Honest Thief posted:

Anyone has a decent workflow for working with svg animations that they can share?
I need to make some svg animations handed down by the designers and I get the idea, and how svgs work, but I can't draw one for the life of me, so animating them and experimenting can get tricky.

If what I'm getting what you're saying, I guess ideally the h1 element would be a shared component that handled the default styles on its own. Otherwise, something with the :global keyword?

Ah, maybe I've been thinking about it wrong since I've been living in AngularJS world, an H1 component (or something named like Heading) would be a much better idea then multiple components with an h1 element that is dependent on an external style.

# ? Aug 6, 2018 18:05

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

ddiddles posted:

Ah, maybe I've been thinking about it wrong since I've been living in AngularJS world, an H1 component (or something named like Heading) would be a much better idea then multiple components with an h1 element that is dependent on an external style.

I have Heading, SmallHeading, and LargeHeading components since I use three sizes a lot. Each will also add in any className you give it. So if I need a Heading inside the SomeBox component to look slightly different, I can do <Heading className="SomeBox__Heading" /> to it and SomeBox css can do what it needs to do.

# ? Aug 6, 2018 18:57

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

HaB posted:

k so - have a thing I am looking for a good approach to take with.

I have some 71 icons I need to use in my app. They are in svg format so they can be styled and resized as needed. They are only all ever used in one place: the signup path, because the user has to select one which then becomes their avatar. The avatar gets used elsewhere in the app. Eventually, the app will have some social functions, such as user profiles and messaging, which would mean needing to load other user's avatars, but right now it does not - only the one the currently logged in user picks.

In total, the path data for all of them comes to roughly 1.4mb total.

Option 1: My initial implementation was to just basically stick them on the bottom of the index.html page in a hidden element and reference them by id when I need one.
Pros: easy to grab since all you need is a string for the id, meaning when social features eventually get added, it's trivial to pull ANY user's avatar
Cons: swells the index page a good bit, but I mean - is 1.4 mb a lot these days?

Option 2: Make them Vue components, and store the symbol for the Avatar in user storage, or session storage.
Pros: does NOT swell the index page, and I have seen a few solutions for lazy loading components
Cons: plenty of tedious copy/paste work to make them components

Option 3: Stick them on the bottom of the signup page, since that's the only place they are all used, store the avatar pick in session, and create an avatar component which loads based on the avatar pick
Pros: solves the index problem
Cons: will have to be refactored once I eventually DO add social features

Option 4: ????

I'm open to suggestions here.

Shoot me some ideas, or some thoughts on the above ideas.

I must be missing something, can't you just load each one asynchronously? Maybe prefetch the next few in either direction if you like. Why do you need to include them all at once?

# ? Aug 8, 2018 13:49

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 23:22

Dominoes: Sep 20, 2007

Hey bros. What's the simplest way to make the browser back button work in React? Most of what I google involves non-trivial code restructuring and boilerplate.

What I'm trying to do can be described by this pseudocode:

JavaScript code:

class Main extends React.Component<MainProps, MainState> {
// ...

    back() {
        let goTo = 0
        if (this.state.page === 0) {
            window.NativeBack()
            return
        } else if (this.state.page === 2) {
            goTo = 1
        }
    this.setState({page: goTo})

    window.onBackButton={back}

    // ...
}

The examples on This page seem orthogonal to this.

edit: The accepted answer on This SO post seems to work! Short and easy. edit: Doesn't actually work standalone, but prevents the user from resetting the page when clicking back, which is a 90% solution.

Dominoes fucked around with this message at 15:04 on Aug 8, 2018

# ? Aug 8, 2018 14:20

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

«‹›235 »