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 »

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

Aquarium of Lies posted:

Assuming you're using the useContext hook to get to the context later, I wrap the hook to "fix" the TS declaration.

code:

const fooContext = React.createContext<FooStuff | null>(null);
function useFooStuff(): FooStuff {
  return useContext(fooContext)!; // if you haven't seen the ! before, it's a shortcut to tell TS "this isn't null/undefined/"empty""
}

// later on

const fooStuff = useFooStuff() // not null!;

Ahahh, yes I've always got a hook to access the context, and re the !, I have a vague memory of seeing it in the docs but never really looked at it as it's so rarely used. That's spot on though, it'll make things a lot easier going forward, cheers.

RobertKerans fucked around with this message at 23:55 on Jan 7, 2021

# ? Jan 7, 2021 23:52

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 11:36

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

RobertKerans posted:

Ok, so say I have a context in React, and I'm using TypeScript. Issue I've got is. If I type the context like this:
code:
React.createContext<FooStuff>({ ...a_load_of_default_values})
That works, but the issue is that often I don't have default values -- for example, the values may be calculated before being added to context, or there may be a large number of them, or they may be highly context [heh] sensitive. atm I'm writing a small graphing package for the app I'm working on, and I can't have a default graph, it entirely depends on data that isn't there to start off with. Aaanyway, I can't do this:
code:
React.createContext()
Because createContext takes one argument. I could do this:
code:
React.createContext<FooStuff | null>(null)
But that's wrong because then null then goes and poisons the rest of my code (it's never going to be null except for when it's first instantiated). I can do this:
code:
React.createContext<Partial<FooStuff>({})
But that's also wrong, because now I have to put guards in any time I want to access properties held in context in case they're undefined.

And this is static, mainly primitive, read-only properties. When I have functions held in context it generally gets substantially more complicated and annoying.

This is driving me slowly insane, I use context quite a bit and most of the time I use it I spend a half hour or so googling solutions to above issue. Is there a sensible way to do this in TS that I'm just missing here

This article has lots of good info on context, and also goes into just this issue. IIRC the solution is similar to what Aquarium suggested, but a good read anyway! https://kentcdodds.com/blog/how-to-use-react-context-effectively

# ? Jan 8, 2021 00:26

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

I do like that article a lot, it's basically informed how I've written code using context for the past year or so, but I've found it doesn't actually solve the issue I was having most of the time. Solution (handling it better in the hook) seems stupidly obvious to me in retrospect now, but he doesn't really do that. He's checking if access is literally undefined, which it will be if access is attempted outside of that component tree, but it doesn't really help with typing context. I've been back and forth through this article umpteen times, and despite him saying he fixes typing errors, beyond the specific example I don't see how he does?

# ? Jan 8, 2021 00:32

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

RobertKerans posted:

I do like that article a lot, it's basically informed how I've written code using context for the past year or so, but I've found it doesn't actually solve the issue I was having most of the time. Solution (handling it better in the hook) seems stupidly obvious to me in retrospect now, but he doesn't really do that. He's checking if access is literally undefined, which it will be if access is attempted outside of that component tree, but it doesn't really help with typing context. I've been back and forth through this article umpteen times, and despite him saying he fixes typing errors, beyond the specific example I don't see how he does?

Because when you use it exposed in the way he does it, it cannot be undefined, so it can only be properly typed. If you don't have values for your context yet... don't render it.

# ? Jan 8, 2021 21:47

Aquarium of Lies: Feb 5, 2005; sad cutie

she/her; Taco Defender

RobertKerans posted:

I do like that article a lot, it's basically informed how I've written code using context for the past year or so, but I've found it doesn't actually solve the issue I was having most of the time. Solution (handling it better in the hook) seems stupidly obvious to me in retrospect now, but he doesn't really do that. He's checking if access is literally undefined, which it will be if access is attempted outside of that component tree, but it doesn't really help with typing context. I've been back and forth through this article umpteen times, and despite him saying he fixes typing errors, beyond the specific example I don't see how he does?

His solution is the same thing, just better written. Here's a hook from the article:

code:

function useCountState() {
  const context = React.useContext(CountStateContext)
  if (context === undefined) {
    throw new Error('useCountState must be used within a CountProvider')
  }
  return context
}

TS can deduce that useContext may returned undefined, but because we check and throw if it is undefined, the final return can not be undefined. This is a better approach than my example, as my example can still cause hard-to-troubloshoot TypeErrors at run time, while his solution will give the more useful error.

# ? Jan 8, 2021 22:30

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Sorry if anyone mentioned it and I missed it. Any tips on how to get a message received via websocket to trigger a JavaScript `Notification`? It seems like browsers have disabled notifications for anything other than user initiated events.

Kinda eliminates any usefulness of notifications imo. But regardless I'd like to notify users.

https://developer.mozilla.org/en-US/docs/Web/API/notification

# ? Jan 9, 2021 15:08

The Fool: Oct 16, 2003

If they�re on your site, could t you have the client poll for messages at some interval, then deliver the message when it sees one.

But otherwise yeah, browser based background notifications require user opt-in and aren�t even supported on iOS as far as I know.

# ? Jan 9, 2021 22:33

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I have opt in and I have messages arriving in the browser. I'm asking specifically about making it so the browser doesn't ignore it when I tell it to show a notification. Because it seems like that only works when it's in response to the user doing something. I haven't tried putting it into a webworker yet. Will that then work again like it used to?

# ? Jan 9, 2021 23:42

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

Nolgthorn posted:

I have opt in and I have messages arriving in the browser. I'm asking specifically about making it so the browser doesn't ignore it when I tell it to show a notification. Because it seems like that only works when it's in response to the user doing something. I haven't tried putting it into a webworker yet. Will that then work again like it used to?

Funnily enough, even though a web worker supports the notification api, the modern browser doesn't really show the notification anymore.

I think you should just use the push api.

# ? Jan 10, 2021 00:41

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

does anyone use a shared business-logic library at work to share code among a website, ios, and android apps?

We're starting to use Kotlin multiplatform:

https://kotlinlang.org/docs/reference/mpp-share-on-platforms.html

And frankly I hate it because now all the Kotlin code is getting compiled to JavaScript and included as a script tag, meaning all the functions have to be accessed on the window object. And now I have to go searching through docs just to see how some piece of code works, that I'd rather just write myself in JavaScript.

# ? Jan 12, 2021 21:00

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

Feels like if you want to share code between website and native apps you should be using React Native or flutter or whatever.

# ? Jan 13, 2021 02:55

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

prom candy posted:

Feels like if you want to share code between website and native apps you should be using React Native or flutter or whatever.

Realistically this doesn�t work well either. In my experience the best you can really do is share types across server and client codebases which yeah react native works with nodejs and probably flutter works with Java idk. It�s not nearly as big a value add as the marketing makes it sound.

# ? Jan 13, 2021 05:12

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

Yeah I dunno to me sharing code is overrated? Like just look at the business logic in one app and then implement the same logic in the other app. Any good programmer should be able to follow what's happening even if it's a language they're not pro at.

# ? Jan 13, 2021 05:31

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

yeah it's not ideal. I don't even think any other library was even vetted, so if we made the wrong choice :shrug:

welp. Plus we have full teams for each platform, so it's not like we don't have the bandwidth to do the same implementation 3 times.

And the worst part is the Kotlin JS NPM library has no tree shaking, so you end up installing and importing a 1MB file if you want to go the ES6 module route, which is why we opted to host our own minified JS and include is as a script tag and avoid that. So now my web team is sacrificing our developer experience for the other teams.

I'm really loving pissed about this, actually

# ? Jan 13, 2021 07:01

uncle blog: Nov 18, 2012

Trying to wrangle some divs into animating nicely. Is there a consensus about the best way to collapse a container with a dynamic height? I've seen different approaches, from giving it a container that hides overflow and then giving it a negative margin to slide it into a void, having flexbox animate when its height gets set to 0 (this requires a parent object with a specified height, making it a no-go), or writing a bunch of JS to get and manipulate the height.
I've also seeing more and more talk about using web animation api, which is fairly supported now? Is that simply a more performant way of doing this stuff, or does it have some unique tricks to make stuff easier? A big hurdle is also how cluttered the css quickly gets.

Edit: Also, I'm doing it in React, which might make things easier/harder.

uncle blog fucked around with this message at 23:54 on Jan 14, 2021

# ? Jan 14, 2021 23:32

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

It has its own issues, but you could CSS transition its max-height.

Initially, give it a max-height of something really large, then when you want it to animate, add a class with a max-height of 0.

# ? Jan 15, 2021 00:45

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

Using JS to get the full height and then animating the CSS between that and 0 has been the most consistent for me.

# ? Jan 15, 2021 03:30

uncle blog: Nov 18, 2012

I'll try both, thanks. Is there a easy way to detect - in React - when an animation is finished, so that I then can remove the jsx element?

# ? Jan 15, 2021 11:43

RadiRoot: Feb 3, 2007

uncle blog posted:

I'll try both, thanks. Is there a easy way to detect - in React - when an animation is finished, so that I then can remove the jsx element?

Something like this? remove would undo the state.

onTransitionEnd={() => remove()}

# ? Jan 15, 2021 18:35

Queen Victorian: Feb 21, 2018

This is the kind of stuff that makes me kinda miss jQuery - .slideUp() would take care of everything in this scenario, including handling a callback to run upon completion.

For all the problems React solves, one of my major gripes with it is that it makes adding transitions and other UI sugar an ordeal when it used to be trivially easy.

Nowadays I rely on a UI component library to handle these sorts of things and so far I�ve not run into a scenario that one of these prefab components couldn�t handle. Otherwise I have useEffect() for D3 animation safe spaces.

And a question of my own:

Is Formik the React form library of choice these days? I naively thought that since our app didn�t have much of the way of forms I could get away with not bothering with a form library, but it turns out that even small forms in plain React are pretty annoying and now it�s coming out that we will likely be adding some form-heavy functionality down the road so I want to be able to handle it. I�ve used Formik before (about a year and a half ago at my previous job) and back then I found the docs and examples pretty obtuse and it also left a bad taste in my mouth from arguing with sexist prick coworker about how to apply it. Anyhow, I checked it out again the other day and it seems way more polished and better documented than before. Also this time I don�t have any pricks to deal with.

# ? Jan 15, 2021 22:59

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

Formik is good, I think, and has a lot of great features. It's made my life better more than once.

e: Also I miss slideUp()

# ? Jan 15, 2021 23:02

Ima Computer: Oct 28, 2007; Stop all the downloading!

Help computer.

react-hook-form is a nice option if you like pure hooks without any bespoke components

# ? Jan 15, 2021 23:42

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

When I was researching form libraries a few months ago, I was convinced into the no-form-library camp, but...

fireraiser posted:

react-hook-form is a nice option if you like pure hooks without any bespoke components

...is what I almost went with.

React state with context or reducer hooks is really all you need (that and a fleshed out collection of input components)

# ? Jan 16, 2021 00:41

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

Formik is good, I think you can do it all with hooks now. You can build your own set of hooks and context instead but... why?

And yes .slideUp() and .slideDown() were the poo poo. I had to do some work with jQuery this week though and everything else sucks compared to the beautiful new world.

# ? Jan 16, 2021 05:41

smackfu: Jun 7, 2004

It�s not that complex to write your own good form in React but you end up with boilerplate functions that are very similar to what formik has already.

# ? Jan 16, 2021 14:21

Harriet Carker: Jun 2, 2009

I have been using Formik for the last year or so and I've been pretty happy with it.

# ? Jan 16, 2021 17:06

biceps crimes: Apr 12, 2008

Queen Victorian posted:

Is Formik the React form library of choice these days? I naively thought that since our app didn�t have much of the way of forms I could get away with not bothering with a form library, but it turns out that even small forms in plain React are pretty annoying and now it�s coming out that we will likely be adding some form-heavy functionality down the road so I want to be able to handle it. I�ve used Formik before (about a year and a half ago at my previous job) and back then I found the docs and examples pretty obtuse and it also left a bad taste in my mouth from arguing with sexist prick coworker about how to apply it. Anyhow, I checked it out again the other day and it seems way more polished and better documented than before. Also this time I don�t have any pricks to deal with.

Formik's great, especially when you use Yup for field validation. My caveat to that is to make sure to only validate on blur, otherwise it'll validate every field for every key-stroke, which induces some pretty heavy performance costs. I don't understand why it's the default setting out of the box. And even if it's set to validate on blur, you may need additional code to handle async calls that go out to services to validate the field, such as checking if the field name is available and not unique, and other such use cases. We have custom wrappers on our Yup package as part of our component library that solve some of these problems we've run into, much of it boils down to memoizing the function calls based on the inputs.

A challenge we've had with Formik in our code base are people adding their own handlers in parallel for things such as data model management, dynamically appended/deleted form fields (just use FieldArray!), injecting formik as props without any clear reason to do instead of using the formik context provider, and on and on, but that folds into a broader problem we have with a large code base with many contributors and a component library being misused by people who aren't experienced with front end. Part of that is on us for not having our poo poo in an ideal state and some problems with discovery that we're actively working on solving.

All of that aside, Formik's been a big help in a broader effort to refactor and consolidate the many ad-hoc forms sprinkled throughout our monolith and various side apps, as well as pages that should be forms but aren't and are written with one off custom state management, validation and asynchronous submission error management. We've made it part of our component library with wrapped Formik components, and some exported modules as well, to enable other teams to move faster with their forms and not all have to independently solve problems that are pretty common with validation/error management/state asynchrony.

e: Oh yeah, I came in to ask about microfrontends. I'm not super hot on them with the few POCs I've worked on during hackathons and for evaluation, but we have some architects pushing hard for it. I think we have bigger problems to solve, and it seems like the user gets the shaft with the possibilities that micro frontends allow, such as heavy initial loads for the various micro apps on the page, etc. I think it may fall into shiny bauble syndrome and am not hot on it but am meeting resistance when I express skepticism. Has anyone adopted microfrontends at work? What are your thoughts?

biceps crimes fucked around with this message at 18:18 on Jan 23, 2021

# ? Jan 23, 2021 18:13

Queen Victorian: Feb 21, 2018

gay_crimes posted:

Formik's great, especially when you use Yup for field validation. My caveat to that is to make sure to only validate on blur, otherwise it'll validate every field for every key-stroke, which induces some pretty heavy performance costs. I don't understand why it's the default setting out of the box. And even if it's set to validate on blur, you may need additional code to handle async calls that go out to services to validate the field, such as checking if the field name is available and not unique, and other such use cases. We have custom wrappers on our Yup package as part of our component library that solve some of these problems we've run into, much of it boils down to memoizing the function calls based on the inputs.

A challenge we've had with Formik in our code base are people adding their own handlers in parallel for things such as data model management, dynamically appended/deleted form fields (just use FieldArray!), injecting formik as props without any clear reason to do instead of using the formik context provider, and on and on, but that folds into a broader problem we have with a large code base with many contributors and a component library being misused by people who aren't experienced with front end. Part of that is on us for not having our poo poo in an ideal state and some problems with discovery that we're actively working on solving.

All of that aside, Formik's been a big help in a broader effort to refactor and consolidate the many ad-hoc forms sprinkled throughout our monolith and various side apps, as well as pages that should be forms but aren't and are written with one off custom state management, validation and asynchronous submission error management. We've made it part of our component library with wrapped Formik components, and some exported modules as well, to enable other teams to move faster with their forms and not all have to independently solve problems that are pretty common with validation/error management/state asynchrony.

Thanks! My inquiry into Formik actually came about in part after trying to figure out how to run Yup by itself with my homegrown form handlers and then thinking it would be less annoying to just use it while already rolled into Formik, which would in turn make it easier to deal with future forms down the road.

At my previous job, it took a long time for Formik to click with me (all the while taking flak from the rest of the team for being slow at it), partly because of (at the time) lacking documentation and partly because rear end in a top hat coworker (who was also new to Formik) insisted on doing stuff in ways that ended up being suboptimal or plain wrong, and because he was the �React expert� brought on board to deliver us from jQuery, we had to go along with his incorrect methodologies (he was actually kind of a bad coder and compensated for it with ego). All in all, I had a really rough start with Formik and will need to teach myself actual good practices.

But this time around, I�m in charge of everything frontend so I get to implement things as I see fit. Also it�s a very small team and I�m technically the only frontend person, so when the fullstack devs chip in on frontend, they follow my lead. Also helps that we�re doing a ground-up rewrite so everything (other than the one form I�ve already written) will be built from scratch.

Oh yeah, I got positive feedback from the team lead for reevaluating a thing on its own merits and separating it from all the bad experiences that aren�t directly its fault. :sun:

# ? Jan 23, 2021 20:53

biceps crimes: Apr 12, 2008

The documentation really isn�t the best, especially if you�re using typescript, and I�ve seen it result in people duplicating features it already has with custom code multiple times. It�s definitely a downside to the library, but I still think it�s the best option for what�s out there in the React ecosystem. It sounds like you�re in a good spot

biceps crimes fucked around with this message at 21:06 on Jan 23, 2021

# ? Jan 23, 2021 21:03

uncle blog: Nov 18, 2012

In TS, I want to add an object to an existing array. The new object is possibly undefined, and I only want to add it if it isn't undefined. What's the most elegant way of doing it?

This is what I'm doing now, which feels clunky:

code:

const possiblyUndefined = allCars.find(car => car.id === id);

let newCarsArr = [...state.cars];
if (possiblyUndefined) {
	newCarsArr.concat(possiblyUndefind)
}
return {...state, cars: newCarsArr }

I feel like I should be able to do something without the if and the temp array.

# ? Jan 24, 2021 00:50

Empress Brosephine: Mar 31, 2012; by Jeffrey of YOSPOS

I don't know TS but does it support ternerary operators because that's what you'd want to use

# ? Jan 24, 2021 01:17

biceps crimes: Apr 12, 2008

uncle blog posted:

In TS, I want to add an object to an existing array. The new object is possibly undefined, and I only want to add it if it isn't undefined. What's the most elegant way of doing it?

This is what I'm doing now, which feels clunky:
code:
const possiblyUndefined = allCars.find(car => car.id === id);

let newCarsArr = [...state.cars];
if (possiblyUndefined) {
	newCarsArr.concat(possiblyUndefind)
}
return {...state, cars: newCarsArr }
I feel like I should be able to do something without the if and the temp array.

code:

const possiblyUndefined = allCars.find(
  (car) => car.id === id
);

const cars = [
  ...state.cars,
  possiblyUndefined,
].filter(Boolean);

return { ...state, cars };

// or

const cars = [
  ...state.cars,
  allCars.find((car) => car.id === id),
].filter(Boolean);

return { ...state, cars };

be careful with the Boolean object, it'll filter undefineds but won't catch empty objects, empty arrays, string of "false", etc.

or for using ternary

code:

const possiblyUndefined = allCars.find(
  (car) => car.id === id
);

let cars = [
  ...state.cars,
  ...(possiblyUndefined
    ? [possiblyUndefined]
    : []),
];
return { ...state, cars };

The spread operator for Array literals does nothing if its operand is an empty Array, but can be cryptic. I prefer the first code block using Array.prototype.filter()

biceps crimes fucked around with this message at 02:05 on Jan 24, 2021

# ? Jan 24, 2021 02:02

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

Also remember Array.concat() returns the new array, it doesn't mutate an existing array, so if you call concat on an array without assigning the return value to a variable, you're not doing anything.

# ? Jan 24, 2021 02:41

Kumquat: Oct 8, 2010

gay_crimes posted:

e: Oh yeah, I came in to ask about microfrontends. I'm not super hot on them with the few POCs I've worked on during hackathons and for evaluation, but we have some architects pushing hard for it. I think we have bigger problems to solve, and it seems like the user gets the shaft with the possibilities that micro frontends allow, such as heavy initial loads for the various micro apps on the page, etc. I think it may fall into shiny bauble syndrome and am not hot on it but am meeting resistance when I express skepticism. Has anyone adopted microfrontends at work? What are your thoughts?

What problem are they intended to solve at your job? We did a lovely implementation last year and now I have to go through and try to unfuck it without creating a bunch of rework/headaches. The problems we were trying to solve (the team owning the codebase not having the bandwidth to gatekeep/review every team's contributions and a rapidly inflating suite of flaky integration tests) were organizational and have largely been solved by other initiatives (collective ownership of that codebase and only running critical path integration tests for PR builds). Now to create a new micro frontend there's a ton of overhead/infra/pipeline stuff you have to set up.

Trying to solve some of the problems we created with Webpack Module Federation but it's fairly new and there are some issues for us still.

tldr; I think there's maybe a couple use cases that make sense but IME it's definitely just shiny new poo poo someone wants to use as a bullet point on their resume

# ? Jan 24, 2021 02:50

biceps crimes: Apr 12, 2008

Kumquat posted:

What problem are they intended to solve at your job? We did a lovely implementation last year and now I have to go through and try to unfuck it without creating a bunch of rework/headaches. The problems we were trying to solve (the team owning the codebase not having the bandwidth to gatekeep/review every team's contributions and a rapidly inflating suite of flaky integration tests) were organizational and have largely been solved by other initiatives (collective ownership of that codebase and only running critical path integration tests for PR builds). Now to create a new micro frontend there's a ton of overhead/infra/pipeline stuff you have to set up.

Trying to solve some of the problems we created with Webpack Module Federation but it's fairly new and there are some issues for us still.

tldr; I think there's maybe a couple use cases that make sense but IME it's definitely just shiny new poo poo someone wants to use as a bullet point on their resume

It's definitely shiny new poo poo syndrome. Someone looked at what it's supposed to solve, said "we have those problems too!", and then have been trying to connect all problems to this silver bullet. They got a hammer, and now everything looks like a nail.

My team has a monolith and we are slowly growing the number of teams and contributors in the code base, we have roughly 40-50 people actively contributing code. We're the "code owners" and are supposed to enable the other teams with CI/CD, instrumentation, CX ops concerns, component libraries, security problems, user identity, etc etc. Sometimes we get pulled onto PRs or someone trips a CODEOWNERS required review, but we're not really blocking the other teams.

I don't really see how MFE address any of our top desired outcomes as a team for the next couple of quarters, and I've made my case with product and they're agreeing with me, but a lot of this debate on both sides is conjecture, so I was just curious if I was blocking our path towards the promised land, or if it was the cluster gently caress that I imagined it would be. I think architecture wants to draw lines in the code base that match the org chart, but it sounds like a headache, and I've experienced a monolith being decomposed into microservices needlessly before, and it was a massive loving headache with no net benefit to anyone except resumes.

Maybe it would be a net benefit in some future state? I just don't think it helps us with our desired outcomes with the state of things. I don't think that accelerating UI development and easing onboarding for new teams and developers is helped by adding another layer of complexity.

biceps crimes fucked around with this message at 03:13 on Jan 24, 2021

# ? Jan 24, 2021 03:07

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

I think MFE makes sense in a general way, but to actually be useful you�ve got to have an app and company structured in a very particular way at some minimum size. Like I think Spotify uses it, but they have also structured the whole company around it to make it work. I hadn�t done any research into it until my boss mentioned it in a 1v1, and got that if-it-was-a-new-project-from-scratch-then-sure sort of feeling from it.

# ? Jan 24, 2021 03:58

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

Spotify is the one company I can think of that has done MFE and frankly the quality of the product does not speak to the validity of the approach.

# ? Jan 24, 2021 06:01

Doom Mathematic: Sep 2, 2008

uncle blog posted:

In TS, I want to add an object to an existing array. The new object is possibly undefined, and I only want to add it if it isn't undefined. What's the most elegant way of doing it?

This is what I'm doing now, which feels clunky:
code:
const possiblyUndefined = allCars.find(car => car.id === id);

let newCarsArr = [...state.cars];
if (possiblyUndefined) {
	newCarsArr.concat(possiblyUndefind)
}
return {...state, cars: newCarsArr }
I feel like I should be able to do something without the if and the temp array.

The other suggested solutions seem to do some unnecessary array and object copying. Based on your code, if possiblyUndefined is undefined, you don't want to modify the array or the state object at all, so I would go with something like:

JavaScript code:

const possiblyUndefined = allCars.find(car => car.id === id);

return possiblyUndefined === undefined
  ? state
  : {
    ...state,
    cars: [
      ...state.cars,
      possiblyUndefined
    ]
  };

# ? Jan 24, 2021 14:15

Doom Mathematic: Sep 2, 2008

dupersaurus posted:

I think MFE makes sense in a general way, but to actually be useful you�ve got to have an app and company structured in a very particular way at some minimum size. Like I think Spotify uses it, but they have also structured the whole company around it to make it work. I hadn�t done any research into it until my boss mentioned it in a 1v1, and got that if-it-was-a-new-project-from-scratch-then-sure sort of feeling from it.

I've heard that Spotify itself never properly implemented the "Spotify model" and/or that it didn't work for them. Anyway, we started developing a brand new cloud application following the Spotify model. To make sure our terms are clear here, in practice what this meant for us was that each of 6-12 teams, with different functional responsibilities, was responsible for the full stack of that functionality, including UI components associated with that functionality. The idea was that each team would send a representative to a "UI Guild" which would meet regularly and keep everybody on track and following the same standard practice.

This did not work out very well for us. Many of these teams had no FE experience, and were just not ready to be handed a job like that. Getting everybody to coordinate also turned out to be extremely difficult. For example, if we collectively decided to move from one framework to another, or tried to fix packaging issues, this created 6-12 separate tasks, one per team. This seems counterproductive to begin with, but of those 6-12 tasks, 3-6 of the teams would flat-out ignore them, either due to lack of technical ability, or other functional requirements taking priority. "Hey, everybody, this common library which we've had since very early on? We're deprecating it. Stop using now and migrate to the alternatives we've set up." Tumbleweed. Completion of the overall task was of course gated on the last team, with the result that some tasks took years or are still incomplete as I write this.

Essentially, as I understand it, MFE is an intentional decision to fragment FE responsibility across multiple teams instead keeping it centralised with one team of specialists. As others have said, I don't fully understand what problem this fragmentation is intended to solve.

# ? Jan 24, 2021 14:36

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 11:36

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

Doom Mathematic posted:

This did not work out very well for us. Many of these teams had no FE experience, and were just not ready to be handed a job like that. Getting everybody to coordinate also turned out to be extremely difficult. For example, if we collectively decided to move from one framework to another, or tried to fix packaging issues, this created 6-12 separate tasks, one per team. This seems counterproductive to begin with, but of those 6-12 tasks, 3-6 of the teams would flat-out ignore them, either due to lack of technical ability, or other functional requirements taking priority. "Hey, everybody, this common library which we've had since very early on? We're deprecating it. Stop using now and migrate to the alternatives we've set up." Tumbleweed. Completion of the overall task was of course gated on the last team, with the result that some tasks took years or are still incomplete as I write this.

when we did this, it was actually easier to just have teams style the app to look similar without sharing code to give the facade of an integrated application. not saying it wasn't a horrible waste of time or degraded the experience, but it did make scrum metrics look a lot prettier to not wait on the ui team.

# ? Jan 24, 2021 17:54

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

«‹›235 »