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 »

Volguus: Mar 3, 2009

HexiDave posted:

I wasn't into it at first either, but it also means that I don't have to fuss with SASS/LESS and weird import mechanisms. It also lets you customize component styles much more easily than hoping you were specific enough to override some other styles elsewhere. The name mangling only happens when you do a production build - they're all named after the React components they're styling in development mode.

If you look at the component style overriding options for Material-UI, you'll see some of the power you get with very little work.

And, yeah, Javascript has permeated into everything, but React being married to a Javascript styling system - especially when it all works out of the box with Typescript - is pretty incredible and has saved me a lot of effort over the last year or two.

Does JSS work with (or on top of ) popular CSS packages (bootstrap, semantic, foundation, material, etc.) or do you have to start from scratch if there isn't a JSS package for your preferred CSS?

# ? Apr 5, 2019 17:22

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 18:55

my bony fealty: Oct 1, 2008

CSS in JS is awesome. It had a rough start and for a while was pretty meh but is a joy to use now. I've written React projects with CSS, Sass, Stylus, and Styled Components and the last is what I would choose 100% of the time going forward.

I know how CSS works and I think the cascade is just fine. It's not about that, its about a styling solution that fits with the component-based architecture of React. "But my separation of concerns" is meaningless; you're almost certainly already writing JSX. It does not exist because JS developers don't want to write CSS, it exists because it is an excellent way to add styling to React projects that allows styling on a component-level basis and alleviates the need for arbitrary naming schemes like BEM.

Pretty much all of the issues with it - JS object syntax instead of writing CSS, difficulty with nesting/cascade, lack of real class names - have been solved by now. With styled components you literally write (S)CSS, the syntax is identical. Linaria and Emotion have copied this as well now and it's great.

There are some valid concerns about increased bundle sizes. Has not been an issue for me but ymmv.

Try it, you might like it.

# ? Apr 5, 2019 18:51

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

CSS in JS is the best because it is a perfect solution for the paradigm mismatch between CSS and components.

# ? Apr 5, 2019 18:55

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

If the advantage of CSS in JS is the style is encapsulated into the component in order to prevent conflicts with Cascading, then how do you cascade when you want to?

# ? Apr 5, 2019 19:25

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

Thermopyle posted:

CSS in JS is the best because it is a perfect solution for the paradigm mismatch between CSS and ~~components~~ anything.

FTFY

# ? Apr 5, 2019 19:36

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

CSS-in-JS is awesome. Just because HTML, CSS, and JS are different languages does not mean they're different concerns. The concern is the view layer. Things that change together should most likely live together.

That being said I am very curious about utility-first CSS lately. But that's basically CSS-in-Markup and most people's first reaction to it (including myself) is :barf:

# ? Apr 5, 2019 19:50

my bony fealty: Oct 1, 2008

The Merkinman posted:

If the advantage of CSS in JS is the style is encapsulated into the component in order to prevent conflicts with Cascading, then how do you cascade when you want to?

in styled components parent components send their styles down to their children. so if you have <Parent>{props.children}</Parent> where Parent is a styled component, all those styles get passed down to its children. if any of those children are styled components then their rules will take precedence and you don't have to worry about some class on the parent or anywhere else in the component tree accidentally conflicting with the child, the magic compiler figures it out for you.

theres also a global style function which is useful for resets and styling html and body and base styles and the like.

another very helpful thing you can do to rely on props instead of classes for rule variations. this is lets you do reactive stuff and is extremely useful if you are trying to design a consistent style system used by many people. writing nested ternaries or using a function in the classNames prop sucks, better to have each possible variation driven by it's own specific prop. this does probably generate some yucky classnames tho.

my bony fealty fucked around with this message at 20:01 on Apr 5, 2019

# ? Apr 5, 2019 19:54

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

prom candy posted:

CSS-in-JS is awesome. Just because HTML, CSS, and JS are different languages does not mean they're different concerns.

Yeah, I've been saying this for years. Separating HTML, CSS, and JS is carving reality at the wrong joints. The joint we should be interested in separating is not at languages, its at concepts.

# ? Apr 5, 2019 20:22

Queen Victorian: Feb 21, 2018

But it's just so antithetical to how I approach styles and theming :psyduck:

.

Again, I come from a pure design background and I started out dealing with CSS almost exclusively and wasn't concerned with/aware of the underlying component structure, just making the thing as a whole presentable, which I could do with just a stylesheet and zero knowledge of the code. Then I got more hands-on with the HTML template part of the components and enforced consistent markup and class rules. Now I build entire components, but still like keeping the styling on a separate plane because I just don't think about styling in a per-component way. But we don't also separate the HTML (because that's dumb) - our JS components generate the HTML (currently by appending template literals, eventually by rendering JSX).

If I'd started out at this job and there was CSS-in-JS instead of a plain CSS stylesheet, I would have been up poo poo creek. I don't want to have styling that's inaccessible to a non-coding designer because that was me once.

As for the gibberish class names only being in production, I still wouldn't want them in production. Our customers run their own instances of this application, so it's not like there's a singular production instance to tend to - there have been times when I've logged onto customer instances to examine some weird-rear end display bug caused by some edge case with their data or something, and it's VERY nice to see your classes and poo poo exactly how you wrote them so you can easily pinpoint what's causing it and go replicate it and figure out a fix.

All that said, CSS has its issues and our current CSS is a train wreck (I know because I wrote it :v:

). It's very, very easy to write extremely disorganized and lovely CSS, I'll give you that. Even so, most of our problems can be solved with SASS (implementation of which has been on my to-do list for like four years) and properly implementing a UI component library with unified base styling.

# ? Apr 5, 2019 22:02

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

Queen Victorian posted:

I don't want to have styling that's inaccessible to a non-coding designer because that was me once.

One of the supposed selling points of JSX and something like styled components is that they're accessible to non-coding designers. How well that pans out in practice I don't know.

Like everything its a matter of tradeoffs and if designers have to get comfortable opening a .js file to edit CSS rather than a .css file I think that's well worth it because overall CSS-in-JS makes way more sense.

I mean, look at this straight from the styled-components home page:

code:

const Button = styled.a`
  /* This renders the buttons above... Edit me! */
  display: inline-block;
  border-radius: 3px;
  padding: 0.5rem 0;
  margin: 0.5rem 1rem;
  width: 11rem;
  background: transparent;
  color: white;
  border: 2px solid white;

  /* The GitHub button is a primary button
   * edit this to target it specifically! */
  ${props => props.primary && css`
    background: white;
    color: palevioletred;
  `}
`

render(
  <div>
    <Button
      href="https://github.com/styled-components/styled-components"
      target="_blank"
      rel="noopener"
      primary
    >
      GitHub
    </Button>

    <Button as={Link} href="/docs" prefetch>
      Documentation
    </Button>
  </div>
)

That's CSS right there, and I have a hard time imagining designers can't figure out how to write that in short order.

If CSS-in-JS was the way it was always done, I don't think most would be arguing that we drop that for a system resembling traditional CSS.

# ? Apr 5, 2019 22:28

Dominoes: Sep 20, 2007

Is CSS-in-JS referring to inline style, and packages that wrap them? I appreciate how they keep display items self-contained, ie not paging through multiple files for one thing. My general rule, is to use CSS file for setting per-tag defaults, then setting specific behavior using inline styles. Overall, it keeps the program better-integrated, in the same way JSX-etc does compared to templates.

Dominoes fucked around with this message at 00:17 on Apr 6, 2019

# ? Apr 6, 2019 00:08

my bony fealty: Oct 1, 2008

Naw there are generally actual style tags involved, that are generated in your JS bundle and injected at runtime in to the DOM elements as classes. I dunno the mechanics about how it works exactly but most popular libraries don't use inline styling (anymore). Inline styling in JSX does count as CSS-in-JS I guess, I dont like how quickly it gets messy and camel casing properties personally.

Linaria is particularly interesting in that it extracts your styles into actual CSS stylesheet files instead of wrapping it all up in the JS bundle. I havent used it seriously but now that it borrowed the styled template literal from styled components I plan to try soon.

# ? Apr 6, 2019 00:26

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.

At the risk of getting beaten to death I'd like to say I generally do not like the way React likes to basically create a conglomerate of HTML/CSS/JS in a single file and is one of the reasons I tend to prefer using Angular or Vue if possible.

# ? Apr 6, 2019 09:08

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

Ape Fist posted:

At the risk of getting beaten to death I'd like to say I generally do not like the way React likes to basically create a conglomerate of HTML/CSS/JS in a single file and is one of the reasons I tend to prefer using Angular or Vue if possible.

That's exactly what I don't like about React either. It just looks like an awful mess to my eyes.

# ? Apr 6, 2019 14:16

spacebard: Jan 1, 2007; Football~

HaB posted:

That's exactly what I don't like about Angular either. It just looks like an awful mess to my eyes.

Fixed

I try to make leaner Angular templates but there really is no way around using directives for control structures and it turns into an awful mess.

Thermopyle posted:

One of the supposed selling points of JSX and something like styled components is that they're accessible to non-coding designers. How well that pans out in practice I don't know.

I thought this selling point boiled down to that designers don't code so give the front end coder all the tools they need in the language that they want? Though that point always bothered me because the separation of design, front end, site building and coding is not always so clear cut.

I get Styled Components and the specificity gains, but I don't think it helps make a large web app or site's CSS anymore easier to remember or learn than sticking with a class-based approach like BEM or utility CSS.

I feel too restricted by encapsulated styles, and usually want the freedom to cascade and limit the number of style definitions I need.

# ? Apr 6, 2019 14:42

Dominoes: Sep 20, 2007

spacebard posted:

[T]he separation of design, front end, site building and coding is not always so clear cut.

Great explanation of why this form of categorization (code, and CSS file and syntax separation) isn't always appropriate.

# ? Apr 6, 2019 14:54

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

The Guardian just posted this article about their CSS situation and it applies pretty nicely to this discussion. Kinda long but well worth reading: https://www.theguardian.com/info/2019/apr/04/revisiting-the-rendering-tier

Adam Wathan (the Tailwind guy) has also done some great writing about separation of concerns as it applies to CSS and some of the pitfalls of semantic CSS: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/

# ? Apr 6, 2019 15:25

PlaneGuy: Mar 28, 2001; g e r m a n
e n g i n e e r i n g; Yam Slacker

pro-tier: CSS style sections in component code that add specific styles to the component. looks like CSS. cascades like CSS. can have local generated names (smart ones append your original class name).

scrub-tier: a set of JS methods that set CSS properties in a component. the css-like syntax is translated into style properties. doesn't cascade. uses className as the class property in markup.

# ? Apr 6, 2019 17:21

Dominoes: Sep 20, 2007

my bony fealty posted:

Naw there are generally actual style tags involved, that are generated in your JS bundle and injected at runtime in to the DOM elements as classes. I dunno the mechanics about how it works exactly but most popular libraries don't use inline styling (anymore). Inline styling in JSX does count as CSS-in-JS I guess, I dont like how quickly it gets messy and camel casing properties personally.

Linaria is particularly interesting in that it extracts your styles into actual CSS stylesheet files instead of wrapping it all up in the JS bundle. I havent used it seriously but now that it borrowed the styled template literal from styled components I plan to try soon.

Thank you. What are the main advantages of this over inline styles? Inline styles (eg the `style` attribute) are built into the DOM spec, and are therefore framework agnostic, unless a framework wraps them. In a framework I made, I wrapped them in an Enum, to make it easier for the coder and IDEs to determine you've used a valid style, and assist with auto-completion. (Vice strings, which feel sloppier) - but left the rest unchanged.

# ? Apr 6, 2019 18:07

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

Dominoes posted:

Thank you. What are the main advantages of this over inline styles? Inline styles (eg the `style` attribute) are built into the DOM spec, and are therefore framework agnostic, unless a framework wraps them. In a framework I made, I wrapped them in an Enum, to make it easier for the coder and IDEs to determine you've used a valid style, and assist with auto-completion. (Vice strings, which feel sloppier) - but left the rest unchanged.

CSS-in-JS just generates style tags, which are also framework agnostic. (Though, I will note that I find this to be a very very minor consideration. Sites just don't get rewritten in a new framework without major changes to CSS anyway)

inline styles only support a subset of CSS.

For example, you can't do this:

code:

import styled from 'styled-components';

const Box = styled.div`
  &:after {
    content: "";
    display: table;
    clear: both;
  }

  @media screen and (min-width: 750px) {
    background-color: seagreen;
  }
`;

However, I find the main advantage to be conceptual. It just makes more sense to me.

# ? Apr 6, 2019 19:44

my bony fealty: Oct 1, 2008

on this topic does anyone have recommendations for styling in React Native? does styled components work the same there? I finally bothered to get Expo and Android Studio running and am not sure how to approach styles. I know it's all flexbox which is great.

# ? Apr 6, 2019 21:06

Hed: Mar 31, 2004; Fun Shoe

Lumpy posted:

I use redux-first-router when I use redux and I love it. https://github.com/faceyspacey/redux-first-router

Speaking of routing, I'm working on a project that's too small for Redux (and might not get that big for a long time) and I have an aversion to react-router and was wondering what others are using if they are using something else!

Thanks for the rec! I like it so far but I'm having trouble figuring out how to organize my pages now. Do you usually do something like

code:

export default function App() {

  return (
    <Provider store={store}>
      <div>
        <NavBar />
        <Content />
      </div>
    </Provider>
  );
};

And then just have Content serve up a component based on what Page would be from the route? Or am I thinking too react-router for a SPA? A lot of the examples are doing a whole lot of UniversalComponent stuff that I can't wrap my head around (and I don't need SSR/SEO optimizations for this)

Ahz posted:

That's just a library which syncs your existing react router state with redux.

You may be better off investigating your double firing issue as you have several levers at your disposal w/React to skip renders.

I looked into redux-first-router, but it seems his full fledged redux based router as his @next (rudy, i think) has never materialized after over a year of talking about it being just around the corner. It doesn't seem like faceyspacey has the traction or will to stick with something long term.

Thanks for this, I ended up converting over just to get everything into redux but you're right. I had some weird invocation that made it so transitioning from a route params -> another valid route params caused an event to fire as well as clicking the link in the first place. I think that will be done with now that everything is in redux.

# ? Apr 7, 2019 03:34

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

Hed posted:

Thanks for the rec! I like it so far but I'm having trouble figuring out how to organize my pages now. Do you usually do something like
code:
export default function App() {

  return (
    <Provider store={store}>
      <div>
        <NavBar />
        <Content />
      </div>
    </Provider>
  );
};
And then just have Content serve up a component based on what Page would be from the route? Or am I thinking too react-router for a SPA? A lot of the examples are doing a whole lot of UniversalComponent stuff that I can't wrap my head around (and I don't need SSR/SEO optimizations for this)

Thanks for this, I ended up converting over just to get everything into redux but you're right. I had some weird invocation that made it so transitioning from a route params -> another valid route params caused an event to fire as well as clicking the link in the first place. I think that will be done with now that everything is in redux.

For my main �page� area, I have a connected component called PageSwitcher that renders top level stuff based on location.

EDIT: very similar to how his �minimal� example works. https://github.com/faceyspacey/redux-first-router/tree/master/examples/minimal/src

Lumpy fucked around with this message at 05:55 on Apr 7, 2019

# ? Apr 7, 2019 05:52

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

Lumpy posted:

For my main �page� area, I have a connected component called PageSwitcher that renders top level stuff based on location.

EDIT: very similar to how his �minimal� example works. https://github.com/faceyspacey/redux-first-router/tree/master/examples/minimal/src

Yeah. Same. That�s actually a pretty clean implementation, mine is just a bunch of conditional components based on route.

# ? Apr 7, 2019 06:40

smackfu: Jun 7, 2004

We have 100% unit test coverage for our React app and I consider it pretty worthless since it is still very easy to make mistakes on component interfaces and break things that the unit tests would never catch.

Has anyone come up with a good solution to this, like adding another layer of integration tests to test the whole app (or parts of it)?

# ? Apr 8, 2019 13:07

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

I like the react-testing-library approach of only testing DOM output and not really bothering with unit tests for components. If you or your employer can spare the cash I thought TestingJavascript.com was a really good video series, it's pretty React-centric and done by the guy who created react-testing-library.

# ? Apr 8, 2019 14:41

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

So when VS Code works, it�s pretty decent. However, that is when it works. Autocomplete stops working intermittently, and has died completely as of yesterday. Sometimes after 2 minutes of use it starts eating 100% CPU, sometimes I can go for several hours...

Is that normal, and just the facts of life with an Election app?

# ? Apr 8, 2019 15:12

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

smackfu posted:

We have 100% unit test coverage for our React app and I consider it pretty worthless since it is still very easy to make mistakes on component interfaces and break things that the unit tests would never catch.

Has anyone come up with a good solution to this, like adding another layer of integration tests to test the whole app (or parts of it)?

This:

prom candy posted:

I like the react-testing-library approach of only testing DOM output and not really bothering with unit tests for components. If you or your employer can spare the cash I thought TestingJavascript.com was a really good video series, it's pretty React-centric and done by the guy who created react-testing-library.

Unit testing components is somewhat pointless. React already has unit tests, you don�t need to duplicate them.

# ? Apr 8, 2019 15:14

lunar detritus: May 6, 2009

Lumpy posted:

So when VS Code works, it�s pretty decent. However, that is when it works. Autocomplete stops working intermittently, and has died completely as of yesterday. Sometimes after 2 minutes of use it starts eating 100% CPU, sometimes I can go for several hours...

Is that normal, and just the facts of life with an Election app?

What plugins did you install? That has never happened to me and I use it every day.

# ? Apr 8, 2019 15:23

evilfunkyogi: Jun 27, 2005

smackfu posted:

We have 100% unit test coverage for our React app and I consider it pretty worthless since it is still very easy to make mistakes on component interfaces and break things that the unit tests would never catch.

Has anyone come up with a good solution to this, like adding another layer of integration tests to test the whole app (or parts of it)?

Use TypeScript :v:

You can use enzyme's shallow rendering and write tests that assert against the props that are passed to child components, but that may already be something you're doing.

# ? Apr 8, 2019 16:22

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

Lumpy posted:

So when VS Code works, it�s pretty decent. However, that is when it works. Autocomplete stops working intermittently, and has died completely as of yesterday. Sometimes after 2 minutes of use it starts eating 100% CPU, sometimes I can go for several hours...

Is that normal, and just the facts of life with an Election app?

I find VS Code to be one of the more responsive apps I use (once it's started up)...but I only use it for single-file short-ish things in a variety of languages. When I was trying to use it for larger projects before I went back to a jetbrains IDE like PyCharm I don't recall having any sort of issues like you describe.

Don't you just love it when something that seems to work for everyone else just fucks up for you and everyone is all like..."works for me!"?

# ? Apr 8, 2019 17:36

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

lunar detritus posted:

What plugins did you install? That has never happened to me and I use it every day.

VIM emulation. That�s it.

# ? Apr 8, 2019 18:58

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

Lumpy posted:

VIM emulation. That�s it.

Yeah that's kind of how it works... do have to say it's a very faithful emulation of VIM though.

# ? Apr 8, 2019 19:06

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

Scaramouche posted:

Yeah that's kind of how it works... do have to say it's a very faithful emulation of VIM though.

So that plugin breaks VS Code? It�s a passable vim emulator, but I�ll just go back to the real thing which actually functions and doesn�t turn my Mac into a space heater. :v:

# ? Apr 8, 2019 19:50

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

Lumpy posted:

So that plugin breaks VS Code? It�s a passable vim emulator, but I�ll just go back to the real thing which actually functions and doesn�t turn my Mac into a space heater.

I was joking about how bad an editor VIM is

# ? Apr 8, 2019 21:50

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

Lumpy posted:

VIM emulation. That’s it.

I get the autocomplete giving up every so often. I don't get the fans issue, but I do get cmd-v just flat out not pasting sometimes. Afaics it's the vim plugin. But I like vscode too much to switch away from it and I like having the vim plugin too much to disable it so I just put up with it occasionally being a pain in the rear end :shrug:

# ? Apr 9, 2019 02:07

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

Scaramouche posted:

I was joking about how bad an editor VIM is

If anyone wants to see just how bad and wrong a post can be, I have quoted the baddest and wrongest post right here.

# ? Apr 9, 2019 02:51

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

Double post action!

So a while back, some kind soul showed me how to do absolute imports in a typescript Create React App. Worked wonderfully! However... Storybook does not see to know about this whole importing thing and explodes when I try to use them. Not that huge of a deal, since I can just use relative there, but if anyone has encountered this and solved it, I would love to hear about it!

EDIT: I done did figure it out all on my own! Tweaked .storyboard/webpack.config.js like so:

JavaScript code:

const path = require("path"); // <-- added this
module.exports = ({ config }) => {
  // added line below
  config.resolve.alias['@'] = path.resolve(__dirname, '../src');
  // rest of your regularly scheduled config....
}

Lumpy fucked around with this message at 03:50 on Apr 9, 2019

# ? Apr 9, 2019 03:27

duz: Jul 11, 2005; Come on Ilhan, lets go bag us a shitpost

RobertKerans posted:

I get the autocomplete giving up every so often. I don't get the fans issue, but I do get cmd-v just flat out not pasting sometimes. Afaics it's the vim plugin. But I like vscode too much to switch away from it and I like having the vim plugin too much to disable it so I just put up with it occasionally being a pain in the rear end

Yeah, I leave it running over night and sometimes in the morning the language server has crashed so I have to restart it. But that's it, ever had any other issues.

# ? Apr 9, 2019 14:34

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 18:55

giogadi: Oct 27, 2009

Hey y�all, I�m trying to build a web app that lets you play a virtual synthesizer, where you interact with the synth by turning knobs, moving sliders, manipulating a step sequencer, etc. I�m also interested in exploring new UX for manipulating sound.

Building this will likely require implementing some custom widgets. Is it considered better practice to try to build new widgets with html+css, or to just have a canvas that handles all the rendering and interaction logic?

I have a lovely prototype of what I want using a canvas where I paint shapes and lines with js to draw my widget, because that was easier for me than learning html/css, haha. I�m just curious about whether there�s a �right� way to do this.

# ? Apr 10, 2019 14:52

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

«‹›234 »