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 »

ModeSix: Mar 14, 2009

Grump posted:

Also now realizing with firebase, there's no such thing as JOINing data

If a document has a reference to data in another document, you have to do multiple round trips to the server.

so...
JavaScript code:
    componentDidMount() {
    getCocktails().then(response => {
      return response.map(eachCocktail => {
        eachCocktail.ingredients.map((eachIngredient: any) => {
          return getIngredient(eachIngredient.name)
            .then((response: any) => console.log(response))
        })
      })
    })
  }
https://stackoverflow.com/questions/47100446/firestore-document-references-can-you-expand-the-document-server-side/47107572#47107572

p loving annoying

Or you could use a Cloud Function instead of simply brute forcing the database using the client computer, which is probably better anyways because uh queries are a thing.

Dominoes posted:

I tried it recently to host a project when having trouble with Github pages routing... it's a PITA to set up; requires loads of config. Moved to Netflify, which was commit and done.

For simple static hosting it's literally this:
* firebase init -> in this step make sure you specify your project build folder for hosting
* BUILD YOUR PROJECT USING WHATEVER
* firebase deploy

Really don't see where the complexity and loads of config lies, not only that but you can connect a domain to it easily (set up the DNS with your domain host and validate it through the firebase console) and it will automagically give you a free SSL certificate.

# ? Jan 5, 2019 14:44

Adbot: ADBOT LOVES YOU

# ? Jun 3, 2024 16:06

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

ModeSix posted:

Or you could use a Cloud Function instead of simply brute forcing the database using the client computer, which is probably better anyways because uh queries are a thing.

I took a look but not so sure this solves my problem.

Specifically the issue i�m having is that I want to do a GET request to return a list of cocktails that contain ingredients I supply.

So I want to send a request to /liquors with an array of [�vodka�, �cream�] and get back [�white russian�].

So I have 2 tables: cocktails and liquors.

Cocktails contain many liquors while liquors can belong to many cocktails. But also cocktails contain a list of liquors.

Is this something NOSQL handles well or should I switch to a relational model?

This might be a question for a different thread as well

# ? Jan 5, 2019 22:16

ModeSix: Mar 14, 2009

Grump posted:

I took a look but not so sure this solves my problem.

Specifically the issue i�m having is that I want to do a GET request to return a list of cocktails that contain ingredients I supply.

So I want to send a request to /liquors with an array of [�vodka�, �cream�] and get back [�white russian�].

So I have 2 tables: cocktails and liquors.

Cocktails contain many liquors while liquors can belong to many cocktails. But also cocktails contain a list of liquors.

Is this something NOSQL handles well or should I switch to a relational model?

This might be a question for a different thread as well

I believe you may need a relational database for that, though I'm not entirely sure. Firestore may enable this -> https://firebase.google.com/docs/firestore/data-model

I believe (though I've not personally used it) GraphQL may allow you to do what you're looking for. Someone else in this thread would likely know better.

ModeSix fucked around with this message at 15:53 on Jan 6, 2019

# ? Jan 6, 2019 15:43

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

Grump posted:

I took a look but not so sure this solves my problem.

Specifically the issue i�m having is that I want to do a GET request to return a list of cocktails that contain ingredients I supply.

So I want to send a request to /liquors with an array of [�vodka�, �cream�] and get back [�white russian�].

So I have 2 tables: cocktails and liquors.

Cocktails contain many liquors while liquors can belong to many cocktails. But also cocktails contain a list of liquors.

Is this something NOSQL handles well or should I switch to a relational model?

This might be a question for a different thread as well

By saying you have "tables" I think your brain may be stuck in relational mode. For a NOSQL approach for this, you have one "document" (or whatever your flavor of NOSQL calls it) and you store duplicate stuff all over the place. So you generally do something like so:

code:

/
    drinks/
        white_russian/
            ingredients[ 'vodka', 'cream', ... ]
            ...
        ...
    ingredients/
        cream/
            drinks['white_russian', 'cement_mixer', .... ]
            ...
        ...

This lets you get drinks that have cream and vodka in it by grabbing the 'drinks' field off the ingredients and then checking for common items. For "simple" stuff, this works out pretty well, but obviously now your DB schema lives in your code. If you want normalized data, use a relational database.

# ? Jan 6, 2019 16:13

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

Thanks. I think I'm going to end up dropping firebase and NoSQL. I know Firebase says that duplicating data is fine, but it seems like I'm basically just creating two very similar documents, at that point.

I've been looking at GraphQL and GraphCMS this afternoon and it looks promising. Honestly this project is just so I have something more recent to put on a resume, so I might just end up learning some Python/Flask to make me look better.

# ? Jan 6, 2019 21:23

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

Grump posted:

Thanks. I think I'm going to end up dropping firebase and NoSQL. I know Firebase says that duplicating data is fine, but it seems like I'm basically just creating two very similar documents, at that point.

I've been looking at GraphQL and GraphCMS this afternoon and it looks promising. Honestly this project is just so I have something more recent to put on a resume, so I might just end up learning some Python/Flask to make me look better.

Definitely for another thread, but please make sure you have a solid understanding/experience with relational databases if you're gonna start applying around (I assume from your comment on padding your resume). GraphQL is cool and new, but SQL's been around for a long time and is good.

# ? Jan 7, 2019 16:17

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

hot take: nosql is almost always bad

# ? Jan 7, 2019 16:32

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

Thermopyle posted:

hot take: nosql is almost always bad

Yeah I was gonna reply last night (but held off) saying I don�t understand what�s so revolutionary about noSQL anyway.

If you want noSQL or someSQL (trademark me) just create some json columns in SQL. Better yet, store it in a traditional relational format and return it as nested JSON where necessary through stored procedures that serve as get interfaces. But the cost of denormalizing data in your db for anything more than trivial applications seems terrible.

Good luck when the name of an ingredient vendor is updated and you need to traverse thousands of documents to correct all the references. Or any time you want to do non-trivial analytics.

# ? Jan 7, 2019 16:44

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

Ruggan posted:

Good luck when the name of an ingredient vendor is updated and you need to traverse thousands of documents to correct all the references. Or any time you want to do non-trivial analytics.

But marketing says that's totally not going to happen!!!

# ? Jan 7, 2019 16:51

Volguus: Mar 3, 2009

Thermopyle posted:

hot take: nosql is almost always bad

Relational DB + document store (or some other nosql) can be quite nice though. Get the best of both worlds.

# ? Jan 7, 2019 17:50

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

Just Kramering into the thread to express my simultaneous awe and frustration for modern web dev.

~7 years ago I did "Web 2.0" development for a large PHP intranet site (when jQuery was the height of technology), and recently I needed to set up a small intranet site so I figured I'd check out what all the cool kids were doing these days. What I got was what Captain America must have felt like when he got unfrozen.

:psypop:

It's amazing and terrible.

Amazing:
- ES6 / Webpack / Babel / React / HTML5 / Bootstrap / etc are such huge leaps forward. Whatever complaints people have about them today, the old-school way was just so goddamn awful.
- Modern code editing is way better. JSX, source maps, Chrome Dev Tools, etc. The old-school way feels like banging rocks together.
- Docs are way better. MDN is fantastic. StackOverflow seems to have the answer to almost every question.

Terrible:
- There's so much to learn it's hard to know where to start. I feel sorry for people who might want to dip into modern web development. It feels necessary to understand many of the details, because things move so fast that they constantly break.

- Things move really fast. There are a million guides on how to do things, and they ripen faster than bananas. Some guides written in early 2018 no longer work.

- NPM is still a goddamn mess (it was just growing in popularity when I got out). It's crazy that people actually rely on this tool in TYOOL2019.

- There are so many npm libraries. I'm relying on "The State of Javascript 20xx" to tell me what to use, because I ain't got the drat time to look through all these.

Overall, the impression I get is that a lot of new technologies are papering over fundamental problems that need to get solved better. TypeScript/Babel/React all seem to be technologies that will eventually get absorbed into the browser or dev environment, rather than being added on top. There are a million npm libraries that just need to get added to the Javascript API already.

And I imagine that curated dev environments will grow in popularity, because people will want stuff that Just Works rather than spending hours dealing with esoteric config options.

# ? Jan 7, 2019 18:43

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

noSQL is awesome if you really like refactoring things into relational databases a few months after you build them.

re: the react-loadable chat from earlier, that library is for lazy loading components and I think it's basically been replaced by React.lazy()

# ? Jan 7, 2019 18:57

Volguus: Mar 3, 2009

minato posted:

And I imagine that curated dev environments will grow in popularity, because people will want stuff that Just Works rather than spending hours dealing with esoteric config options.

Hah. Not in web development. My impression here is that developers actively seek the latest crap to pursue and config just to avoid doing work (and to look hip).

# ? Jan 7, 2019 18:57

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

Volguus posted:

Hah. Not in web development. My impression here is that developers actively seek the latest crap to pursue and config just to avoid doing work (and to look hip).

I think they seek the latest crap because the crap they just used was crap and maybe this new thing won't be crap. Bad news: it is.

# ? Jan 7, 2019 19:04

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

it's crap in a different way though, which is nice

# ? Jan 7, 2019 19:07

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Modern Web Development: Choose Your Own Crappy Adventure

# ? Jan 7, 2019 19:42

crazysim: May 23, 2004; I AM SOOOOO GAY

Munkeymon posted:

Modern Web Development: Choose Your Own Crappy Adventure

Throw Tea over Computer

# ? Jan 7, 2019 19:49

Dominoes: Sep 20, 2007

minato posted:

Amazing:
- ES6 / Webpack / Babel / React / HTML5 / Bootstrap / etc are such huge leaps forward. Whatever complaints people have about them today, the old-school way was just so goddamn awful.
- Docs are way better. MDN is fantastic. StackOverflow seems to have the answer to almost every question.

Webpack was a (configuration) mess until Webpack 4, but now it's pleasant. Bootstrap solved a problem of layout before Flexbox and CSS-grid were released, which was historically counter-intuitive, but is now no longer needed, due to those two tools.

MDN's wonderful. StackOverflow's often difficult to sort through, due to fast-speed you mentioned; must wade through JQuery-based solns.

quote:

- NPM is still a goddamn mess (it was just growing in popularity when I got out). It's crazy that people actually rely on this tool in TYOOL2019.
- There are so many npm libraries. I'm relying on "The State of Javascript 20xx" to tell me what to use, because I ain't got the drat time to look through all these.

You can get far using modern JS, and avoid most of the libs. Or not

quote:

And I imagine that curated dev environments will grow in popularity, because people will want stuff that Just Works rather than spending hours dealing with esoteric config options.

Hopefully - this has been a historic problem.

I got frustrated and built a frontend framework in Rust, in an explicit attempt to adopt the nice things you've noticed (eg declarative design), and avoid the shortcomings. (Eg complex config, NPM, boilerplate, and glue-code between companion libs)

Dominoes fucked around with this message at 20:44 on Jan 7, 2019

# ? Jan 7, 2019 20:01

susan b buffering: Nov 14, 2016

Doh004 posted:

Definitely for another thread, but please make sure you have a solid understanding/experience with relational databases if you're gonna start applying around (I assume from your comment on padding your resume). GraphQL is cool and new, but SQL's been around for a long time and is good.

GraphQL is great with RDBs as well, and really easy to get going with tools like Postgraphile for postgresql.

# ? Jan 7, 2019 20:22

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

skull mask mcgee posted:

GraphQL is great with RDBs as well, and really easy to get going with tools like Postgraphile for postgresql.

There's also stuff like graphene (and graphene-django) if you've got a app server between your db and outside world.

# ? Jan 8, 2019 00:31

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

i built some graphql stuff on our rails/mysql app to serve our front-end app. works great.

# ? Jan 8, 2019 02:32

my bony fealty: Oct 1, 2008

I am getting back into Laravel after a while and liking it. The community seems to have embraced Vue. Is it typical to use Vue with Blade templates, like how jQuery was used just for DOM interaction and not templating, or should I be looking to do the whole frontend with Vue? Same question is probably applicable to React, unless there's something special about Vue that makes it especially good with Laravel?

Lighthouse GraphQL server for Laravel is super great and easy to work with, uses standard schema definition language which other PHP graphql libraries don't seem to.

# ? Jan 9, 2019 23:04

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

Thermopyle posted:

It's been ages since I did any frontend stuff, but I'm getting ready to start something new.

What's the big changes in React/Redux in the last 18 months? (Or maybe I should tell React/Redux to gently caress off and use something else?)

Should I use create-react-app nowadays? I remember it was just coming out when I last did frontend work and I didn't like it because as soon as I wanted to do something that they didn't support I had to eject the app and it was all weird and poo poo.

# ? Jan 10, 2019 00:14

Dominoes: Sep 20, 2007

Thermopyle posted:

Should I use create-react-app nowadays? I remember it was just coming out when I last did frontend work and I didn't like it because as soon as I wanted to do something that they didn't support I had to eject the app and it was all weird and poo poo.

No, for the reason you've already discovered: Doing anything outside of a specific workflow requires eject, which makes config difficult. Additionally, when I last tried the TS version, it came defaulted with a set of opinionated, style-centered lints. Use Webpack 4: It's simple and transparent in comparison.

React's a JS lib; a build setup explicitly for it could be seen as design smell.

Dominoes fucked around with this message at 00:52 on Jan 10, 2019

# ? Jan 10, 2019 00:31

Harriet Carker: Jun 2, 2009

Thermopyle posted:

Should I use create-react-app nowadays? I remember it was just coming out when I last did frontend work and I didn't like it because as soon as I wanted to do something that they didn't support I had to eject the app and it was all weird and poo poo.

I say yes and immediately eject. You�ll get a project up and running in literally 30 seconds and you�ll be able to tinker to your heart�s desire.

# ? Jan 10, 2019 01:29

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

Thermopyle posted:

Should I use create-react-app nowadays? I remember it was just coming out when I last did frontend work and I didn't like it because as soon as I wanted to do something that they didn't support I had to eject the app and it was all weird and poo poo.

Yes. You can do 99% of the stuff you want to do without ejecting now.

# ? Jan 10, 2019 03:19

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

Dominoes posted:

No, for the reason you've already discovered: Doing anything outside of a specific workflow requires eject, which makes config difficult. Additionally, when I last tried the TS version, it came defaulted with a set of opinionated, style-centered lints. Use Webpack 4: It's simple and transparent in comparison.

React's a JS lib; a build setup explicitly for it could be seen as design smell.

I think the latest typescript CRA is fine. Besides for forcing you to use relative imports, most of the rules seem like they generally help.

# ? Jan 10, 2019 04:01

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

Grump posted:

I think the latest typescript CRA is fine. Besides for forcing you to use relative imports, most of the rules seem like they generally help.

Not sure if the TS version differs, but you can do absolute imports with a config change now in the vanilla one. Also, I am determined to make a small TS react project soon, even if it kills me.

# ? Jan 10, 2019 04:13

Vincent Valentine: Feb 28, 2006; Murdertime

I haven't had to eject in about a year. No reason not to use it anymore, really.

# ? Jan 10, 2019 11:41

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

I�ve used cra for the last year as well with no problems.

# ? Jan 10, 2019 13:44

LifeLynx: Feb 27, 2001; Dang so this is like looking over his shoulder in real-time; Grimey Drawer

Vincent Valentine posted:

I haven't had to eject in about a year.

A Good Sentence.

What's the best React crash course out there? I'm familiar with JavaScript and npm commands now, but there are a million "beginning React" tutorials and I want to make sure I'm starting projects and learning in ways that aren't out of date, because this create-react-app and ejecting talk makes it seem like there are pitfalls to avoid.

# ? Jan 10, 2019 14:22

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

LifeLynx posted:

A Good Sentence.

What's the best React crash course out there? I'm familiar with JavaScript and npm commands now, but there are a million "beginning React" tutorials and I want to make sure I'm starting projects and learning in ways that aren't out of date, because this create-react-app and ejecting talk makes it seem like there are pitfalls to avoid.

As I just mentioned, I've been out of frontend stuff for awhile, but a few years ago I always thought the official React docs were really good because they were small and understandable (by virtue of React being small and understandable).

My recent foray back into this world leads me to still think this.

# ? Jan 10, 2019 15:26

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

So I put a website online recently and a user with a browser/OS I don't have access to (Firefox on linux mint) reported that the webpage wasn't working as intended. They were quite helpful and checked the web developer console. The errors were related to the Content Security Policy. Nobody else has reported an issue and I can't reproduce it on any browser/device I have.

I'm hosting the site statically with AWS S3, Googling around it appears that you can't specify the CSP header with S3 (feel free to correct me if I'm wrong on that point). In the end I was able to fix the issue for this individual by specifying the CSP in a meta tag.

Even though I've fixed the issue, this is my first time dealing with a CSP issue, so I was hoping to get some clarification on a few points. Any information would be helpful:
1) What is the "default" CSP used by the browser if none is specified?
2) Does AWS S3 not specify a CSP at all, or does it have some reasonable default?
3) Why would this break on some browsers and not others? My guess right now is different browsers may assume a different CSP when none is specified? This person's browser seemed to assume an extremely conservative default, refusing to load a .js script under the same domain.
4) Is there a way in the browser developer tools to inspect the CSP?

# ? Jan 10, 2019 15:28

my bony fealty: Oct 1, 2008

Babel macro support in create-react-app is a huge boon and has also allowed me to no longer eject or use rewired.

I wonder if the React team has interest in a more fully-featured cli tool a la vue-cli. Gotta say it's great.

# ? Jan 10, 2019 16:45

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

LifeLynx posted:

What's the best React crash course out there? I'm familiar with JavaScript and npm commands now, but there are a million "beginning React" tutorials and I want to make sure I'm starting projects and learning in ways that aren't out of date, because this create-react-app and ejecting talk makes it seem like there are pitfalls to avoid.

Having just been through this myself (except I was also unfamiliar with Webpack / Babel / TypeScript / etc), I think the official ReactJS tutorials were pretty great for learning the core concepts, and create-react-app was a great playground to try things out in.

Having said that, I will suggest avoiding the following pitfalls:
- They give you a toy web server with webpack-dev-server, and they basically assume you're writing a single-page-app. This wasn't what I wanted to do (I wanted to add it in my Django site) so I struggled a lot with trying to simultaneously learn React and also how to wrangle create-react-app so that it would integrate into my site. Don't do this; just focus on using create-react-app to learn the core concepts, and then worry about how to add React/JSX to your project.
- JSX (the syntactic sugar that allows you to seemingly write HTML inside JS) is not necessary to use React, but it's highly recommended. Installing it requires Babel and all the fun that entails... use create-react-app so that it Just Works.
- Also defer researching other tools/tech you'll see along the way like Redux (state management) or Formik (form management). I googled a few "What I wish I'd known before I started React" and it was common to see people say that they tried to learn too many technologies at once. Play around with React a bit before you do that.
- Realize that React is just a viewing library. It doesn't inform on how to do any other stuff like handle AJAX calls or manage state.
- I was confused for a long time about the subtle difference between React Components and Elements because I had made some assumptions about how class-based Components work. My mistake was that if you have a class-based Component 'Foo' and you write:

code:

return <Foo bar="baz" />

Then this would generate an instance of the class and inject the props {bar:"baz"} into it. This is wrong. It actually just creates an immutable datastructure that refers (by name) to Foo, and also stores those properties:

code:

{
  type: 'Foo',
  props: {
    bar: 'baz',
  }
};

Later on when React tries to render this, it uses the 'type' to determine that it needs to instantiate an ephemeral instance of the Foo class, and then it will pass those props to that instance to generate the HTML fragment it needs. This is clearly explained in the Main Concepts pages of the documentation, but it didn't really click at the time. This is why I recommended using function-based Components where possible, because it really helps drive home that the Components themselves don't contain any of your Element's state.

# ? Jan 10, 2019 18:22

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

I don�t use Formik, I just self manage all my form state. By giving each input a name that matches the state property name, I can handle onChange with a single function.

What does Formik provide, and should I look into using it?

# ? Jan 11, 2019 01:56

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

Ruggan posted:

I don�t use Formik, I just self manage all my form state. By giving each input a name that matches the state property name, I can handle onChange with a single function.

What does Formik provide, and should I look into using it?

I�ve used it, and would not do so again. The amount of effort I put in to use it was equivalent to me just doing everything manually. If for some reason you really need form state in your app state, then it�s not terrible, but if you just have �normal� form use cases, it isn�t worth the overhead in my opinion.

# ? Jan 11, 2019 02:04

geeves: Sep 16, 2004

my bony fealty posted:

Babel macro support in create-react-app is a huge boon and has also allowed me to no longer eject or use rewired.

I wonder if the React team has interest in a more fully-featured cli tool a la vue-cli. Gotta say it's great.

Can anyone explain the benefits of CLI tools for Vue and / or Angular? For someone like me who manages our build process, it's just one more thing that's in the way.

# ? Jan 11, 2019 18:27

spacebard: Jan 1, 2007; Football~

geeves posted:

Can anyone explain the benefits of CLI tools for Vue and / or Angular? For someone like me who manages our build process, it's just one more thing that's in the way.

angular-cli is

1. A theoretically bundler-agnostic build tool (that's why it has its own schema and terminology for angular.json)
2. A generator to scaffold various components, services, etc... in an app.

Unfortunately you get both so if you eject you can't use one if you don't like the other.

I do like some of the recent improvements to the app configuration, and that's allowed me to setup some custom per-environment configuration so that it's much easier to setup test, build and deploy patterns on the CI server.

So I have something like npm run <build|test|e2e>:<env> which translates to ng <bulid|test|e2e> --configuration=<env>

<env> is then a key in angular.json that might include environment specific typescript, proxy configuration, etc...

ng lint however is garbage because warnings are always errors for some dumb reason, and I run tslint to avoid that.

I still don't like Angular bloat at all, but angular-cli has made it relatively painless to get a new project up and running using the same patterns.

# ? Jan 12, 2019 00:26

Adbot: ADBOT LOVES YOU

# ? Jun 3, 2024 16:06

FormatAmerica: Jun 3, 2005; Grimey Drawer

spacebard posted:

...but angular-cli has made it relatively painless to get a new project up and running using the same patterns.

very much this, I remember only a few short years ago pulling together tooling to handle all the various concerns for just starting to scaffold an app (and testing, linting, transpiling, etc.) took many hours, lots of reading docs, and sapped my entire desire to write the drat thing to begin with.

# ? Jan 12, 2019 01:09

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

«‹›235 »