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

«‹›234 »

Spatulater bro!: Aug 19, 2003; Punch! Punch! Punch!

Yeah I've tinkered with the conditional rendering. I've gotten it working, but the issue then becomes that I get a herky jerky page load experience. Everything loads, then some things vanish, then everything reappears. I'm hoping there's a way to get a seamless transition from server-render to final render?

# ? Feb 27, 2019 04:27

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 21:54

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

Spatulater bro! posted:

Yeah I've tinkered with the conditional rendering. I've gotten it working, but the issue then becomes that I get a herky jerky page load experience. Everything loads, then some things vanish, then everything reappears. I'm hoping there's a way to get a seamless transition from server-render to final render?

You'll have to decide what does and doesn't need to be render-blocked by data. If there's some markup that should be rendering, regardless of whether the promise has finished resolving, then it shouldn't be blocked by the if(!this.state.data) return null.

It's hard to give an ironclad answer without seeing the Header component code though.

# ? Feb 27, 2019 04:37

Spatulater bro!: Aug 19, 2003; Punch! Punch! Punch!

The Header component has a couple child components that take the userData (which is an array of objects) and pulls specific properties e.g:

code:

{userData[currentUser].userName}

Is it bad form to do something like this:

code:

{userData.length > 0 ? userData[currentUser].userName : "User Name"}

Basically filling it in with dummy data until final render? That way at least all the components load and the only flash is the names and numbers within the components instead of the components themselves.

# ? Feb 27, 2019 05:09

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

It's a "flash" for you because you're developing locally. But for someone on mobile or a really slow connection, that delay could be a couple of seconds. So I find it's worth designing for that; e.g. having your component render at a minimum size with a "Loading" symbol placeholder.

# ? Feb 27, 2019 05:22

Hed: Mar 31, 2004; Fun Shoe

Is there an easy way to do the generic �light grey block� rendering I see a lot while waiting for things to render?

# ? Feb 27, 2019 10:34

Funking Giblet: Jun 28, 2004; Jiglightful!

Hed posted:

Is there an easy way to do the generic �light grey block� rendering I see a lot while waiting for things to render?

These are called stencils, and there are tons of libs that can do it.

# ? Feb 27, 2019 12:19

Vincent Valentine: Feb 28, 2006; Murdertime

I hate those because I can never tell if something is loading or just broken.

Like with a load spinner I'm too assume that I'm supposed to wait. But those grey blocks just look like something failed to render.

# ? Feb 27, 2019 12:46

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

You should also probably check in componentDidMount if you already have state because as of now I think if you load that page from a server render it'll fetch the data twice, no?

# ? Feb 27, 2019 16:40

Spatulater bro!: Aug 19, 2003; Punch! Punch! Punch!

prom candy posted:

You should also probably check in componentDidMount if you already have state because as of now I think if you load that page from a server render it'll fetch the data twice, no?

Yes, I'm loading it first on the server and then again with componentDidMount. It was my (possibly incorrect) understanding that this is the way it should be.

# ? Feb 27, 2019 19:12

I R SMART LIKE ROCK: Mar 10, 2003; I just want a hug.; Fun Shoe

Based on what I see you're already loading the from the server call and are passing it directly into the app container, and setting initial state based on that. If it needs to be refreshed in some way then you should set that up based on either an action or an interval

Unless I'm missing something you're making 2 API calls for no particular benefit; unless you believe the data could go stale between the initial load and the component mounting

# ? Feb 27, 2019 20:09

Spatulater bro!: Aug 19, 2003; Punch! Punch! Punch!

Perhaps I don't need to call the API the second time, but the problem doesn't come at the componentDidMount phase, it comes at the browser render phase. The initial data that comes in via the server render doesn't get recognized during the browser render. I guess I don't really understand why.

# ? Feb 27, 2019 21:35

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

Spatulater bro! posted:

Yes, I'm loading it first on the server and then again with componentDidMount. It was my (possibly incorrect) understanding that this is the way it should be.

This is why loading data in componentDidMount can be a headache. If you are using a routing library, use the route change to load data, and have the component only reference app state for said data. If you *do* need to use componentDidMount, have a check to see if your "initial____" things are set and then setState directly without making new API calls. Something like:

JavaScript code:

componentDidMount() {
  const {initialUsers, initialContests} = this.props;
  if( initialUsers && initialContests ) {
    this.setState( // set them to what the server passed )
  } else {
    this.setState({ loading: true });
    // do your API calls and set state when they return
  }
}

# ? Feb 27, 2019 21:48

Spatulater bro!: Aug 19, 2003; Punch! Punch! Punch!

So, should the data that loads from the server render be able to carry over into the components once the real render happens? Mine isn't doing that. It never even makes it to componentDidMount because it acts like there's no data right when the app loads (but after a successful brief server-render).

EDIT: after pondering this for a while, it's becoming clearer to me. Why WOULD the data from the server render pass into the client-rendered app? The only thing that gets pushed to the browser is static markup. The data at that point is non-existent. Then the first render happens and there's no actual data for the components to see, and the app falls over. I guess I just need to either a) forget about rendering on the server, or b) use default data to load the problematic components until the AJAX call completes.

Spatulater bro! fucked around with this message at 23:39 on Feb 27, 2019

# ? Feb 27, 2019 22:07

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

Spatulater bro! posted:

So, should the data that loads from the server render be able to carry over into the components once the real render happens? Mine isn't doing that. It never even makes it to componentDidMount because it acts like there's no data right when the app loads (but after a successful brief server-render).

EDIT: after pondering this for a while, it's becoming clearer to me. Why WOULD the data from the server render pass into the client-rendered app? The only thing that gets pushed to the browser is static markup. The data at that point is non-existent. Then the first render happens and there's no actual data for the components to see, and the app falls over. I guess I just need to either a) forget about rendering on the server, or b) use default data to load the problematic components until the AJAX call completes.

c) Render your data as JSON in the page from the server and hydrate the app state on load.

code:

<script>
const INITIAL_STATE = {"server_stuff": "lalala"}
</script>
... later
<App initialState={ INITIAL_STATE } />

# ? Feb 27, 2019 23:52

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

The vast majority of my app lives behind a login screen so I haven't had to deal with SSR much but I think this is actually one of the biggest things that NextJS tries to solve

# ? Feb 28, 2019 00:30

Spatulater bro!: Aug 19, 2003; Punch! Punch! Punch!

Okay I'm an idiot. I was missing some major steps in rendering my initial data. The tutorial I'm following actually went on to solve my problem, if only I had just soldiered on instead of getting ahead of myself.

Even though I was doing an initial server render with ReactDOMServer, I wasn't passing any data to React. My ReactDOM.render method was passing empty arrays. The page got the first static markup but didn't know what to do next (because it had no data). Turns out I don't even need componentDidMount.

Now my app ships a server render to the browser that's identical to what React is seeing, so React doesn't even re-render. :banjo:

Spatulater bro! fucked around with this message at 04:41 on Feb 28, 2019

# ? Feb 28, 2019 00:53

RobertKerans: Aug 25, 2006; There is a heppy lend
Fur, fur aw-a-a-ay.

I'm taking over work on a React Native app, and all over it is this pattern:

code:

mapState = state => ({ foo: state.foo })

mapDispatch = dispatch => ({ getFoo: () => dispatch(getFooAction()) })

class SomeContainer {
  constructor() {
    this.props.getFoo();

    this.state = {
      foo: []
    };
  }

  componentWillRecieveProps(newProps) {
    this.setState({ foo: newProps.foo });
  }

  render() {
    { someCheckOnFoo ? <SomeComponent foo={foo} /> : <ZeroStateComponent /> }
  }
}

It's a pretty big app, with a load of screens that all pull in data, so this is everywhere, like a rash. I get why the people who originally built the app did it, and at first glance it kinda does make handling missing data or data that's still coming in over the wire a bit easier (?). But notwithstanding the fact CWRP is aliased as `UNSAFE_` and has usage warnings all over the docs, is this at all a common or sensible pattern? It seems, if nothing else, that duplicating the state of the relevant Redux store slice in every container component is a massive footgun

edit: aargh, and they've used some boilerplate-reducing library that obfuscates the redux actions/reducers, and all the reducers are all in one ~1500 line file

RobertKerans fucked around with this message at 14:03 on Feb 28, 2019

# ? Feb 28, 2019 13:37

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 got my way and I'm going to get go integrate a bunch of Angular micro-applications across the Web project we're building. I'm happy enough with it, but jumping back into Angular after a few months of bring out of it and needing it to do a bunch of new customer-facing fanciness is, honestly, sort of annoying.

What makes matters worse is that so many 3rd party libraries and tutorials for angular are, honestly, loving garbage.

# ? Feb 28, 2019 15:25

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

RobertKerans posted:

I'm taking over work on a React Native app, and all over it is this pattern:
code:
mapState = state => ({ foo: state.foo })

mapDispatch = dispatch => ({ getFoo: () => dispatch(getFooAction()) })

class SomeContainer {
  constructor() {
    this.props.getFoo();

    this.state = {
      foo: []
    };
  }

  componentWillRecieveProps(newProps) {
    this.setState({ foo: newProps.foo });
  }

  render() {
    { someCheckOnFoo ? <SomeComponent foo={foo} /> : <ZeroStateComponent /> }
  }
}
It's a pretty big app, with a load of screens that all pull in data, so this is everywhere, like a rash. I get why the people who originally built the app did it, and at first glance it kinda does make handling missing data or data that's still coming in over the wire a bit easier (?). But notwithstanding the fact CWRP is aliased as `UNSAFE_` and has usage warnings all over the docs, is this at all a common or sensible pattern? It seems, if nothing else, that duplicating the state of the relevant Redux store slice in every container component is a massive footgun

edit: aargh, and they've used some boilerplate-reducing library that obfuscates the redux actions/reducers, and all the reducers are all in one ~1500 line file

You should definitely undo this pattern as it's dumb and also relies on lifecycle methods that are going to be deprecated. Sounds like a real pain in the rear end, sorry!

Does anyone know how to do type assertion on a named function in Typescript? I've been googling for it but I can't seem to find the right combination of words, probably because I don't know what anything is called. Basically, when you use this type of function definition

code:

const Foo = (props: Props) => {
  // some stuff
}

You can easily do type assertion like this:

code:

const Foo: React.SFC = (props: Props) => {
 // some stuff
}

But I like to define my components like this:

code:

 
export default function Foo(props: Props) {
  // some stuff
}

But I can't figure out how to type assert that Foo is a React.SFC (so that I can attach defaultProps to it or whatever). Is that something that I can do? Everything I've googled only wants to tell me how to type the args and the return value.

# ? Feb 28, 2019 16:39

RobertKerans: Aug 25, 2006; There is a heppy lend
Fur, fur aw-a-a-ay.

prom candy posted:

You should definitely undo this pattern as it's dumb and also relies on lifecycle methods that are going to be deprecated. Sounds like a real pain in the rear end, sorry!

Fanks, just needed some basic justification that what I was staring at was actually dumb and it wasn't some secretly common pattern that had appeared in the two years I haven't been doing React.

Oh god, and it looks like they've tried about 20 bajillion different approaches to styling the loving thing and now I can't figure out how the hell to use the font they've used for the rest of the app in the new views I've got to build. And it's two react-native minor versions and god knows how many patch version behind. Oh I love agencies, I now have to take all this and spend the next few months bringing it in-house

# ? Feb 28, 2019 18:26

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

I hate taking over projects, it's the worst. Very rarely do devs get kicked off a project because they were doing a great job.

# ? Feb 28, 2019 19:31

RobertKerans: Aug 25, 2006; There is a heppy lend
Fur, fur aw-a-a-ay.

Not quite as bad as it could have been tho. We hired an agency to build the app initially, and then I was hired ~8 months in to bring it in-house once we had MVP; technically they're still building the app (tho I think we've brought it down to half a dev a week in terms of paying them, and they're basically just bugfixing atm), so I can at least quiz the guy who did most of the work on why he made the decisions he did before we wave bye bye to them.

# ? Feb 28, 2019 20:14

Vincent Valentine: Feb 28, 2006; Murdertime

I've had to take over multiple projects that were all many years old, and is evident that everyone who ever worked on them said the same thing. "Whoever wrote this was wrong, I'm gonna do this my way, the RIGHT way!" And maybe it is. The problem is they always get a few months into it before moving on to something else, at which point the new guy says "Whoever wrote this was wrong, I'm gonna do this my way, the RIGHT way!" And the cycle begins anew.

Can't rebuild them, though! That's not Agile Development.

# ? Feb 28, 2019 22:42

I R SMART LIKE ROCK: Mar 10, 2003; I just want a hug.; Fun Shoe

I dunno. I'd argue that, that is accruing tech debt and get it into the sprint anyway. You could sell it as faster future dev time since it'll be less rear end to work with

# ? Feb 28, 2019 23:21

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

Vincent Valentine posted:

I've had to take over multiple projects that were all many years old, and is evident that everyone who ever worked on them said the same thing. "Whoever wrote this was wrong, I'm gonna do this my way, the RIGHT way!" And maybe it is. The problem is they always get a few months into it before moving on to something else, at which point the new guy says "Whoever wrote this was wrong, I'm gonna do this my way, the RIGHT way!" And the cycle begins anew.

Can't rebuild them, though! That's not Agile Development.

This reminds me of something I just read yesterday.

https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22

# ? Mar 1, 2019 00:20

Vincent Valentine: Feb 28, 2006; Murdertime

I read over it, and I really agree for the most part that a rewrite is rarely ideal, but in my particular case everything is a disaster that a re write is desperately needed to solve. We're running two state storage solutions. Three front end frameworks. A sql db, a nosql db, and some hosed up graph system literally no one understands because the guy who developed it left the company without even telling anyone he made it. We have two different servers in two different languages, with a third service layer in a third language that dictates where traffic goes. We use Docker sometimes and sometimes not. This is all for one product, and we have six others that are equally hosed up.

Not only is it unbelievably frustrating to work on anything, it's straight up impossible to hire for. Can you imagine telling someone applying for a front end position that they need to know Vue, angularjs and react, all for just one project? And you might be required to work on other projects, using entirely different techs?

I'm just ranting at this point(in general, not at you) but you get the idea. People basically wanted to just do things their own way, but found out it was frustrating to work on and bailed, immune to the irony that they helped make it even more frustrating.

# ? Mar 1, 2019 01:13

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

Vincent Valentine posted:

I read over it, and I really agree for the most part that a rewrite is rarely ideal,

Its funny, but my read of it was that a rewrite is the best course forward more often then a lot of people would want you to believe.

# ? Mar 1, 2019 01:23

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Well, thanks Vince because I was raging a bit that the Export Report button on our application is inconsistent between categories (e.g. the Accounting sections use an Excel file icon, Inventory use a Printer icon button) but you've outlined a scenario that's way worse and makes me feel a little better about things.

# ? Mar 1, 2019 01:50

Doom Mathematic: Sep 2, 2008

Vincent Valentine posted:

We have two different servers in two different languages, with a third service layer in a third language that dictates where traffic goes.

Microservices!

So, when the "Should we rewrite the application from scratch?" question come up, my feeling is always that the real mistakes have been made long before that point. You should avoid at all costs arriving at a situation where the ground-up rewrite starts to look like an attractive proposition. This is a scenario which you can anticipate, and see coming from a long way off, and intentionally steer away from. The reason the decision is so hard is that neither of the two options - ground-up rewrite, persevere forever - necessarily leads to success, or is necessarily better than the other. It may be that both options lead to disaster. It's possible that the product is doomed before you make the decision, and all you're doing is choosing how it fails.

Entropy in a codebase has to be paid down constantly in order to avoid this scenario. This is something I've been trying to get the team I work in to take on board for a long while. But it can be done.

Obviously this is always a really useful thing to say to someone who's genuinely facing this decision... Sorry...

# ? Mar 1, 2019 02:06

Vincent Valentine: Feb 28, 2006; Murdertime

The issue I largely agree with is that with a rewrite you lose a lot of momentum, and loss of momentum means loss of growth. In order to compensate for losing momentum, you need to be prepared to essentially make a new product.

That's the trend among the success stories. Simply rewriting your code and keeping the feature set isn't enough. In the success stories they end up realizing that their weak code isn't enough to trigger a rewrite, it's weak code combined with spying an opportunity to meet the changed needs of their market.

In our case, I don't believe a shift in direction is necessary. It's just our code that's poo poo, which is a significantly harder sell. I doubt that there's many, if any, features that would really draw in new clients, even if support, development speed and employee satisfaction would all increase dramatically. It's an unfortunate situation where all the developers being sick of it just isn't enough.

The real answer is to just quit, but that's a whole different thing.

# ? Mar 1, 2019 02:12

gbut: Mar 28, 2008; 😤I put the UN🇺🇳 in 🎊FUN🎉

We are about to do a rewrite of a load-bearing system that's about 17 years old. Sometimes you have to pull the trigger. Also, the worst people you can assign to that job are hotheads that like shiny things, as you will end up at the same place you started, only in a newer technology. It helps with hiring for a while, I guess.

# ? Mar 1, 2019 03:11

Ruggan: Feb 20, 2007; WHAT THAT SMELL LIKE?!

RobertKerans posted:

I'm taking over work on a React Native app, and all over it is this pattern:
code:
mapState = state => ({ foo: state.foo })

mapDispatch = dispatch => ({ getFoo: () => dispatch(getFooAction()) })

class SomeContainer {
  constructor() {
    this.props.getFoo();

    this.state = {
      foo: []
    };
  }

  componentWillRecieveProps(newProps) {
    this.setState({ foo: newProps.foo });
  }

  render() {
    { someCheckOnFoo ? <SomeComponent foo={foo} /> : <ZeroStateComponent /> }
  }
}
It's a pretty big app, with a load of screens that all pull in data, so this is everywhere, like a rash. I get why the people who originally built the app did it, and at first glance it kinda does make handling missing data or data that's still coming in over the wire a bit easier (?). But notwithstanding the fact CWRP is aliased as `UNSAFE_` and has usage warnings all over the docs, is this at all a common or sensible pattern? It seems, if nothing else, that duplicating the state of the relevant Redux store slice in every container component is a massive footgun

edit: aargh, and they've used some boilerplate-reducing library that obfuscates the redux actions/reducers, and all the reducers are all in one ~1500 line file

So what�s the right way to structure this?

I�m assuming they built it to load data, stuff that in a reducer, and put said data into local state for editing or something.

If the local state serves no real purpose and is truly duplication then sure that�s moronic and you should just reference the props directly. Detangling that might be a huge pain in the rear end. But if it�s loading redux data into local state for an editable form it makes sense to me?

I just want to make sure I understand what part of it is terrible so I can avoid it in my own code.

# ? Mar 1, 2019 04:23

Ruggan: Feb 20, 2007; WHAT THAT SMELL LIKE?!

One thing I have learned is that a lot of devs want to write complex and �innovative� code, but what they really should be doing is writing simple and easy to maintain code instead.

I�m currently ripping out thousands of lines of jQuery and Razor and C# code from a project I work on because some previous dev wanted to write this really complex integrated widget system for HTML elements, then bailed, and it aged really poorly. I wish he had just used a widely adopted library or plugin instead. I�m replacing it with a fraction of the code in Vue.

Sometimes the best thing you can do for figure devs (including yourself) is write simple, uninteresting code. Pay it forward.

# ? Mar 1, 2019 04:32

RobertKerans: Aug 25, 2006; There is a heppy lend
Fur, fur aw-a-a-ay.

Ruggan posted:

So what�s the right way to structure this?

I�m assuming they built it to load data, stuff that in a reducer, and put said data into local state for editing or something.

If the local state serves no real purpose and is truly duplication then sure that�s moronic and you should just reference the props directly. Detangling that might be a huge pain in the rear end. But if it�s loading redux data into local state for an editable form it makes sense to me?

I just want to make sure I understand what part of it is terrible so I can avoid it in my own code.

That would be ok! And in fact one part of the app does have a fairly lengthy form. And that form does make use of data in the store/remotely.

But the actual local data doesn't get edited in that case, only read. The pattern is used everywhere in the app, and in the main, the app is just displaying info grabbed from various endpoints. It looks like it is the developer's go-to solution for handling loading of remote data & keeping the UI in sync. I might be wrong on that and I need to quiz him about it when he's back next week; he's quite experienced and he'll definitely have, at least, a sensible-at-the-time reason for doing it. Even if that reason is "I've had problems keeping data in sync on previous apps & this happened to work really well for me", that would be OK. But I still think there's going to be a helluva lot to untangle. The app seems far too complicated, and the more I read through the code, the more I can see how layers of cruft have built on top of each other.

Ugh and this app is giving me a deep and unbridled hatred for any library that claims to DRY up redux by abstracting over actions/types/reducers. Redux boilerplate is fine: it's brutally simple, easy to test and really obvious, there's no need to hide it to save a few keystrokes, stop making it complicated already

RobertKerans fucked around with this message at 11:07 on Mar 1, 2019

# ? Mar 1, 2019 11:01

Vincent Valentine: Feb 28, 2006; Murdertime

My biggest concern with redux boilerplate isn't laziness or anything like that, it's that there's up to 4 places where a single piece of state is managed between Selector/Reducer/Action/Type. Having so many different things dictating how one single thing works gives you a lot of places to introduce mistakes. I agree that you shouldn't be using any libraries to simplify the process, however. If someone doesn't like Redux's boilerplate to the point that they want to install another library, another state management system is probably the correct choice.

That being said though wanting to reduce the redux boilerplate is a worthy goal, one that has spawned a lot of great state management systems over the course of just a couple of years.

# ? Mar 1, 2019 11:43

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

Ruggan posted:

So what�s the right way to structure this?

I�m assuming they built it to load data, stuff that in a reducer, and put said data into local state for editing or something.

If the local state serves no real purpose and is truly duplication then sure that�s moronic and you should just reference the props directly. Detangling that might be a huge pain in the rear end. But if it�s loading redux data into local state for an editable form it makes sense to me?

I just want to make sure I understand what part of it is terrible so I can avoid it in my own code.

https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html

The React Docs have a good article about alternatives to derived state.

For an editable form, set the key prop on the form component to the ID of the form data object, then transfer the data from props to state in the constructor. The component will be recreated from scratch whenever the ID key changes.

# ? Mar 1, 2019 13:44

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

Ruggan posted:

One thing I have learned is that a lot of devs want to write complex and �innovative� code, but what they really should be doing is writing simple and easy to maintain code instead.

I�m currently ripping out thousands of lines of jQuery and Razor and C# code from a project I work on because some previous dev wanted to write this really complex integrated widget system for HTML elements, then bailed, and it aged really poorly. I wish he had just used a widely adopted library or plugin instead. I�m replacing it with a fraction of the code in Vue.

Sometimes the best thing you can do for figure devs (including yourself) is write simple, uninteresting code. Pay it forward.

So much this.

I share space at the office with our dev intern - a position which shifts every 3 months or so - and since I sit there, I am sort of the de facto mentor to each of the dev interns. Our latest one was tasked with writing a quick To Do List in Vue in order to get a better handle on JavaScript in general, and to learn Vue, which we use on the app he will be assisting with.

So he was having trouble with a sort function for an array he had written so we pulled it up to take a look, and aside from the issues resulting from not knowing JS very well, he was using a nested ternary a'la:

code:

thing1 ? result1 : thing 2 ? result2 : result3

(I may have that wrong since I would NEVER write that, plus I am simplifying, as his conditionals basically made the statement take up almost the entire 80 char line.) but I basically told him: don't ever sacrifice readability. EVER. I can't think of a single reason to sacrifice readability, and "cleverness" for drat sure isn't one, nor is being a lazy typist. Indenting matters (even in languages that don't count whitespace), punctuation matters, variable names matter, formatting matters.

It is the lot in life of a programmer to constantly be paying for the sins of those who came before us, but I have really tried hard over the last few years to make sure those who come after ME don't have to pay as much as I have. Plus any coder with more than a couple of years under his belt has had the experience of looking at code going "what the hell was this guy doing?" only to realize "this guy" was YOU a year ago.

Vincent Valentine posted:

The issue I largely agree with is that with a rewrite you lose a lot of momentum, and loss of momentum means loss of growth. In order to compensate for losing momentum, you need to be prepared to essentially make a new product.

I think it's possible to rewrite without a loss of momentum, and I have seen it done. I have never worked at a place where you'd be able to sell the idea of a rewrite as: "we are going to HALT work on the old version, and start over to make a new version." That will never fly with any manager, no matter how tech savvy and/or dev-friendly they are. But it's certainly possible to split off a single senior dev to say write a new API or scaffold out a new front-end, while maintaining (and even continuing to iterate/update) the old version. Particularly if you start with something you know is a large problem on the old version and can show metric/value-add, etc by rewriting just that one piece.

We are currently doing something similar where I work now, in that we have a long-running Rails app that we are converting over to a Vue front-end over a rewritten Rails backend. The original Rails devs were not good, didn't understand ActiveRecord at all, nor did they understand basic referential integrity. At any rate, we have basically just been going route by route, page by page, endpoint by endpoint, using ZERO of the old code.

Anyway, rewrites are definitely possible, the trick is just selling it to management so that they will allow you the resources to do it. Even if it's a tiny fraction or single dev from the team. Once you can get a foothold and show them why it's a good road to take, they get a lot warmer about the idea.

quote:

The real answer is to just quit, but that's a whole different thing.

There's always this. :v:

# ? Mar 1, 2019 14:06

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

Yay for double post.

HaB fucked around with this message at 14:22 on Mar 1, 2019

# ? Mar 1, 2019 14:18

RobertKerans: Aug 25, 2006; There is a heppy lend
Fur, fur aw-a-a-ay.

Vincent Valentine posted:

My biggest concern with redux boilerplate isn't laziness or anything like that, it's that there's up to 4 places where a single piece of state is managed between Selector/Reducer/Action/Type. Having so many different things dictating how one single thing works gives you a lot of places to introduce mistakes. I agree that you shouldn't be using any libraries to simplify the process, however. If someone doesn't like Redux's boilerplate to the point that they want to install another library, another state management system is probably the correct choice.

That being said though wanting to reduce the redux boilerplate is a worthy goal, one that has spawned a lot of great state management systems over the course of just a couple of years.

Yeah, I do definitely understand avoiding splitting across files, and it does give me headaches. Reducing edit distance is a generally good thing: eg React components, with the direct representation of the output alongside the logic, are great. But although redux code does spread across files, the way the boilerplate interlinks does provide some level of protection. re abstractions over the whole thing: with types, I really don't like them being generated, as that implies strings, which then implies my app may not instantly explode (+ my editor is not going to scream at me) if I type something wrong. Then situations where the reducers aren't segregated into individual files that represent discrete state slices is pretty annoying. As is avoiding switch statements; given Redux is a state machine that switches states based on input messages, using the syntax explicitly designed for that seems sensible but whatever. Actions and selectors are the two ones where there is the most opportunity for programmer error that isn't very easy to locate I guess. The sheer simplicity of actions kinda guards against that though.

RobertKerans fucked around with this message at 15:25 on Mar 1, 2019

# ? Mar 1, 2019 15:14

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 21:54

Dr. Krieger: Apr 9, 2010

HaB posted:

Yay for double post.

Doing a similar thing with our rails monolith that has major performance and stability issues. Once we were able to gather metrics and show business with a small POC that we could give them new features that were faster and less buggy if they paid the cost of a progressive rewrite it was actually a pretty easy sell. My only worry is that we won't get the time to clean up the stuff that isn't being used heavily once we hit that 80% mark. Really liking Vue, everything feels seamless but that might just be it being so much better than our last framework.

# ? Mar 1, 2019 15:40

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

«‹›234 »