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 »

ndrz: Oct 31, 2003

dantheman650 posted:

Yes, gotta work with time zones. I�m basically making a recurring event scheduler. But the time zone setting is just a global setting and all events will use it for any particular user. I don�t think it should be too bad.

I haven't personally used this, but I also work on a tool that deals with repeating events, and RRULE is the main standard for defining how and when to repeat things.

https://github.com/jakubroztocil/rrule

# ? Jul 16, 2019 15:59

Adbot: ADBOT LOVES YOU

# ? Jun 9, 2024 02:39

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.

prom candy posted:

lol

As an Angular developer literally everything about this is loving true.

# ? Jul 16, 2019 16:23

ynohtna: Feb 16, 2007; backwoods compatible; Illegal Hen

-- �I already am eating from the trash can all the time. The name of this trash can is Angular. The Material UI of ideology makes me not see what I am effectively eating.�

# ? Jul 16, 2019 16:51

Harriet Carker: Jun 2, 2009

ndrz posted:

I haven't personally used this, but I also work on a tool that deals with repeating events, and RRULE is the main standard for defining how and when to repeat things.

https://github.com/jakubroztocil/rrule

Thank you! I�ve been reading about rrule and FullCalendar supports it as well, so it seems like the perfect choice. I�ve got a PoC running already and it�s been a breeze to work with.

# ? Jul 16, 2019 23:18

ConanThe3rd: Mar 27, 2009

Ape Fist posted:

https://hackernoon.com/why-angular-made-me-quit-web-dev-f63b83a157af

So recommend hard skip on learning Angular then?

# ? Jul 17, 2019 10: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.

ConanThe3rd posted:

So recommend hard skip on learning Angular then?

Unless you need it for a job I'd probably recommend you just learn React. The only possible benefit you'll get from learning Angular otherwise is that Vue thereafter becomes a piece of piss to figure out.

edit:

There's some stuff Angular does in my opinion, really well. If you don't mind template Syntax, then Angular's template syntax is pretty good and easy to understand. Native observables with RXJS are very cool and allow you to develop cross-application dependency injection with minimal need for 3rd party state libraries. TypeScript is, actually, pretty good in spite of this article crying about it and the TypeChecking errors are a security feature which exists in almost every single typed language.

There's also some stuff Angular does really badly, and the article touched on it: Angular is incredibly, unnecessarily verbose about everything. This is partly TypeScript's fault because it wants you to loving Type every loving thing in its strictest interpretation. Child -> Parent EventEmitter syntax is garbage. Input event method firing syntax is garbage. Change detection is incredibly resource intensive. And probably the biggest, most critical complaint which the article touched on is that Angular will work fine in development and break, badly, in production and return the most useless loving errors you've ever seen because its throwing them on minified uglified bundles. Angular, when requiring Storage, will offer you no meaningful pattern to build this yourself even though it actually can be built natively within Angular without the need for a 3rd party. At least Vue offers you the Vue.observer({}) pattern to write basic small-scale Storage with Angular you just sort of have to loving figure one out using RXJS & Subscribers.

Ape Fist fucked around with this message at 13:38 on Jul 17, 2019

# ? Jul 17, 2019 13:28

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

ConanThe3rd posted:

So recommend hard skip on learning Angular then?

I will try and provide the moderate's opinion here. I will say right off the bat that I currently use Vue, which I LOVE, have done Angular and AngularJS professionally, and continue to dislike React - for reasons I have already laid out in other posts, so I won't bother repeating my issues here.

The front-end job market these days (at least around Atlanta, where I live) is roughly divided up like:

40% React
40% Angular (including AngularJS, but that's an increasingly small percentage)
15% Vue
5% everything else . (Go, Elm, etc)

Is that Angular article accurate? Eh. A bit over exaggerated, but yeah - it's not far off. Angular is ridiculously opinionated about EVERYTHING. There will be no discussions about "how do you think we should do X?" because Angular will dictate that you're going to do it their way, else ye should Abandon All Hope. Believe me, I beat my head against many walls in this manner early on in my experiences with Angular. You will have a much easier time if you just buy into it whole hog, and if you do that - it's nowhere near as opaque/persnickety/frustrating as that article suggests it is. There is an actual reason for Angular being so opinionated, which is that it's trying to be everything. (whether or not that's a good thing to strive for is up for debate, to be sure). Vue and React both really only cover the V part of MVC whereas Angular wants to be MVC & the kitchen sink, 3 dogs, half a burrito, two turtledoves and a partridge in a pear tree. So of course it's gonna be more opinionated than the other two. I also wouldn't say being opinionated isn't necessarily bad - as long as you agree with its opinion.

The people I have seen bounce off Angular the hardest are the ones who tried to do "Angular but X" where X is something that Angular already does, but they didn't like that particular way of doing it, so tried to do it their own way. In fact, I have NEVER seen that situation turn out well, even when I myself have tried it.

Advice? Eh - it's simple enough to do the To Do List tutorial for each one and figure out which one seems to make the most sense to you, then deep dive into that. They all share some concepts anyway, so even if you don't learn whichever one you end up working on, it's not a HUGE leap to get into the others.

# ? Jul 17, 2019 13:50

lunar detritus: May 6, 2009

My main problem with Angular is that it's too unnecessarily complex for about every possible thing you could use it for.

# ? Jul 17, 2019 14:32

Pollyanna: Mar 5, 2005; Milk's on them.

I have had mixed results at best with Redux.

# ? Jul 17, 2019 14:38

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

Redux works really well. But it�s also very verbose and requires a LOT of boilerplate (or exceptionally clever coding).

# ? Jul 17, 2019 15:21

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

Redux-starter-Kit is the boilerplate killer and it's officially endorsed by the redux core team.

# ? Jul 17, 2019 16:26

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

Is there a way to inline extend an interface in TypeScript?

For example, if we have a component that takes some props, and a function that does things with those props plus an extra arg from somewhere else, it would be nice to do something like this:

JavaScript code:

// inside FooBar.tsx
function doTheThing({ propArgs, extraArg}: { ...FooBarProps, extraArg: string}) { ... }

But it looks like the only way is to either add in everything manually, or extend and add the additional argument in another interface. Is there something I'm missing here? Still pretty new to TS.

# ? Jul 17, 2019 18:43

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.

Use a class?

# ? Jul 17, 2019 18:57

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

The Dark Wind posted:

Is there a way to inline extend an interface in TypeScript?

For example, if we have a component that takes some props, and a function that does things with those props plus an extra arg from somewhere else, it would be nice to do something like this:
JavaScript code:
// inside FooBar.tsx
function doTheThing({ propArgs, extraArg}: { ...FooBarProps, extraArg: string}) { ... }
But it looks like the only way is to either add in everything manually, or extend and add the additional argument in another interface. Is there something I'm missing here? Still pretty new to TS.

Not built in but there's this: https://github.com/piotrwitek/utility-types#assignt-u

JavaScript code:

function doTheThing({ propArgs, extraArg}: Assign<FooBarProps, { extraArg: string}>) {...}

Haven't tried it

# ? Jul 17, 2019 20:06

M31: Jun 12, 2012

Volguus posted:

I unironically do miss SOAP. While I never wrote a web ui that would consume a SOAP service, I wrote a few desktop apps that did. I had my contract (WSDL), I had the generated API, I had the clear cut signatures of methods, an IDE and a compiler that would tell me right away if anything was wrong ... what was not to love?

200 different incompatible implementations? I have an old SOAP service I'm consuming that returns the wrong namespace for random requests. There is also the other 'SOAP' service that returns <attribute><name>foo</name><value>bar</value></attribute> and the actual schema is communicated out of bounds (yes, it's soap, not xml-rpc). Then there is the other service that uses some authentication extension that is not supported by anything else.

All of these services only work if you use their generated client, which all suck because they where generated for Java 4.

# ? Jul 18, 2019 02:33

Lord Of Texas: Dec 26, 2006

Volguus posted:

I unironically do miss SOAP. While I never wrote a web ui that would consume a SOAP service, I wrote a few desktop apps that did. I had my contract (WSDL), I had the generated API, I had the clear cut signatures of methods, an IDE and a compiler that would tell me right away if anything was wrong ... what was not to love?

Look into consumer-driven contracts if you have any relationship with the API provider or you are building it yourself. Everything you mentioned does not have to be abandoned just because you aren't using SOAP.

# ? Jul 18, 2019 02:51

Hed: Mar 31, 2004; Fun Shoe

Guys I checked in months ago about my toy projects and got some help but so far using TypeScript in my project to have the compiler help yell at me has been great and really helped me with my code. Thanks thread.
Also I was really leery of using CSS-in-JS but after reading this thread's comments and using styled-components for a bit I'm starting to really really like it :greenangel:

# ? Jul 18, 2019 04:01

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

styled components is cool but also check out tailwind, I have a huge boner for utility first css right now (probably because I have yet to build an unmaintainable mess with it like I have with every other CSS approach)

# ? Jul 18, 2019 04:53

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

tankadillo posted:

https://twitter.com/ow/status/1148568077065433088

# ? Jul 19, 2019 22:14

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

Who is using Browserstack? Are you happy with it? What plan do you use, and how is that working for you? We have a single SPA that we'd like to test, and Browserstack seems to be a thing that will be helpful!

TIA!

# ? Jul 22, 2019 15:04

Doh004: Apr 22, 2007; Mmmmm Donuts...

Used it at last job, worked pretty well for our manual web QA work.

# ? Jul 22, 2019 15:24

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

Abandoned it after 6 months or random vm fails, mostly for recent mobile but windows too.

e: to add more info, we used it in our CD pipeline for a year and couldn't rely on it. We switched to headless in the end. We ran a barrage of test that would take about half an hour when running on a dozen different platforms, and having them randomly drop out or hang crawled our deployments to a halt. :sever:

gbut fucked around with this message at 15:57 on Jul 22, 2019

# ? Jul 22, 2019 15:51

smackfu: Jun 7, 2004

If we just ignore all the PureComponent and React.memo stuff, how bad off are we if we aren�t noticing any performance issues?

# ? Jul 25, 2019 00:29

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

smackfu posted:

If we just ignore all the PureComponent and React.memo stuff, how bad off are we if we aren�t noticing any performance issues?

if you aren't seeing performance issues you aren't bad off at all no matter what you are doing.

# ? Jul 25, 2019 02:50

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

smackfu posted:

If we just ignore all the PureComponent and React.memo stuff, how bad off are we if we aren�t noticing any performance issues?

You'll know when you need it.

# ? Jul 25, 2019 05:37

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

Got to do some React dev again this week and I was quickly reminded how much I love React. Hooks for useState and useEffect made it trivial to replace some redux and saga code which also felt very nice.

# ? Jul 25, 2019 06:03

The Fool: Oct 16, 2003

I'm looking for some feedback on the best way to do a thing in React.

I have a site with a number of components, that are laid out something like this in index.js:

code:

<Layout>
    <Card />
    <Modal />
</Layout>

The Card components have buttons on them, that need to trigger the Modal with arguments.

Currently I'm thinking the easiest way to do this is to keep the modal state and props as state in my top level component and pass them down to both the cards and the modal, but that feels sloppy and I can't help but feel there is a better way.

# ? Jul 26, 2019 20:38

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

The Fool posted:

I'm looking for some feedback on the best way to do a thing in React.

I have a site with a number of components, that are laid out something like this in index.js:
code:
<Layout>
    <Card />
    <Modal />
</Layout>
The Card components have buttons on them, that need to trigger the Modal with arguments.

Currently I'm thinking the easiest way to do this is to keep the modal state and props as state in my top level component and pass them down to both the cards and the modal, but that feels sloppy and I can't help but feel there is a better way.

That's not sloppy at all. You could also make the Modal a child of the Card if that makes sense? Sometimes if I have components that are like a button and a modal I'll do it like this:

code:

function DeleteButton({ handleDelete }: Props) {
  const [isModalOpen, setIsModalOpen] = useState(false);
  
  return (
    <>
      <button onClick={() => setIsModalOpen(true)}>Delete Thing</button>
      
      <Modal isOpen={isModalOpen} onRequestClose={() => setIsModalOpen(false)} />
    </>
  )
}

Also if I wanna get cute I'll use render props so that the parent component can render whatever it wants for the button and still get access to the sweet juicy insides (the modal)

# ? Jul 26, 2019 21:23

smackfu: Jun 7, 2004

It�s basically this, right? https://reactjs.org/docs/lifting-state-up.html

quote:

Often, several components need to reflect the same changing data. We recommend lifting the shared state up to their closest common ancestor. Let�s see how this works in action.

# ? Jul 26, 2019 22:36

The Fool: Oct 16, 2003

smackfu posted:

It�s basically this, right? https://reactjs.org/docs/lifting-state-up.html

Yeah.

Got it working. Had a minor hurdle figuring out how to call the function to launch modal from the button on the card component but I figured that out too.

Thanks

# ? Jul 26, 2019 22:45

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

Yeah, lift your shared logic/state to the nearest container component and pass props down.

If you're in a situation where the passed down props are drilling through multiple levels of nested components, take a look at react context:
https://daveceddia.com/usecontext-hook/

(If you're not on version 16.8, you can use the old way of context, but its kind of a pain in the rear end and not recommended over passing props)
https://reactjs.org/docs/context.html

# ? Jul 26, 2019 22:46

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

Related to that question, I'm just getting started with React, and although I find it pretty easy to work with, I end up finding that in everything I've done so far, after lifting the state to the nearest parent that can share it with all child components, it seems like most of the state of a given app rests at the very top level, and ends up with callbacks/props getting passed down to children as needed. I don't have a particular problem with doing that way, I just want to make sure I'm not falling into any anti-patterns that I should be avoiding.

The context thing looks like a good way of dealing with this issue as well, but I don't mind the way I've done it so far either.

# ? Jul 27, 2019 06:29

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

Yup that's pretty normal and it's the reason that everyone was reaching for Redux for the past 3-5 years. Redux is still good, especially paired with redux-starter-kit, but you can also just use context if you have a lot of stuff that's getting prop-drilled. The key with context is that unlike Redux, you can't just put all your state in a single "store", you need to have discrete contexts for different things because every component that subscribes to a specific context will get re-rendered any time anything in that context changes. Context is also harder to debug than Redux, but Redux is harder to grok initially.

One other thing is that a lot of people were putting ALL their state into Redux for a while. This is dumb and you shouldn't do it, if something can be local state, it should be local state. Only hoist when you're doing a lot of prop drilling.

https://redux-starter-kit.js.org/
https://kentcdodds.com/blog/how-to-use-react-context-effectively

# ? Jul 27, 2019 14:08

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

prom candy posted:

Context is also harder to debug than Redux, but Redux is harder to grok initially.

I've only used context for smallish projects. Is there anything as good as the Redux chrome extension for debugging context?

# ? Jul 27, 2019 22:04

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

So far I�ve avoided context. I try to keep as much state local* (up to 2-3 levels of prop drilling) and anything deeper usually makes sense to stuff into Redux (like user info, lookup key:value pairs, and similar). Has worked out fine so far.

# ? Jul 28, 2019 21:45

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

Thermopyle posted:

I've only used context for smallish projects. Is there anything as good as the Redux chrome extension for debugging context?

I don't think so, not yet anyway. All the boilerplate/ceremony in redux is really in service of a top-notch debugging experience. I know Brian Vaughn is working on a new version of redux devtools that should be pretty sweet but I don't think you'll get the action logging etc since one half of the redux devtools is the redux middleware you have to include.

# ? Jul 29, 2019 04:14

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

I think it was already mentioned in here before but Svelte is looking like a pretty interesting project. https://daveceddia.com/svelte-intro/

# ? Jul 29, 2019 21:24

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

prom candy posted:

I think it was already mentioned in here before but Svelte is looking like a pretty interesting project. https://daveceddia.com/svelte-intro/

The copy on that page ensures that Svelte will never surgically updates its way onto my computer.

# ? Jul 30, 2019 04:49

smackfu: Jun 7, 2004

In the year 2019, you should not be writing a single-component, no-server-calls to-do app as your framework demo.

This one seems a bit more rounded: https://www.valentinog.com/blog/svelte/

smackfu fucked around with this message at 12:53 on Jul 30, 2019

# ? Jul 30, 2019 12:50

Adbot: ADBOT LOVES YOU

# ? Jun 9, 2024 02:39

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

I think that was just some guy's demo, not their official one. The official tutorial is pretty thorough: https://svelte.dev/tutorial/basics

I'm pretty hesitant to go down the rabbit hole of learning a framework that may or may not catch on ([ASK] me about the year I wasted with Ember) but I do think the idea of compiling the whole app is very interesting.

# ? Jul 30, 2019 14:41

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

«‹›235 »