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

«‹›14 »

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

What's everyone using for forms in a React/Redux environment? React-form-for seems interesting but I don't know if I'm biased towards Rails-y things.

# ¿ Oct 30, 2015 14:32

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 09:10

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

Don't tie your front end to Rails if you can avoid it, sprockets is dog slow and lacks a ton of tooling compared to things like webpack. I'm in the middle of writing a big mountable rails engine which means I have to use the asset pipeline and it's driving me crazy.

If you want to use a combination of Rails views with a few mounted JS components for the more interactive pieces look into something like react_on_rails or webpack-rails to get as much of your asset code as possible away from Rails. You'll thank me when you're getting automatic style injection on save and using proper JavaScript modules.

# ¿ Apr 7, 2016 05:41

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

Kekekela posted:

I feel like this js fatigue thing is seriously overblown, especially given how mature React et al are.

It's just bad developers who hate the idea of ever learning anything new.

Helicity posted:

I should have said "writing custom middleware and keeping action creators fully synchronous" instead of "using middleware".

redux-think *is* middleware, and it essentially just allows you to write action creators that return functions. This sounds benign, but can easily lead to really horrible things with asynchronicity in your action creators. I'm talking about multiple dispatches and setTimeouts and Promises everywhere. Testing and troubleshooting these action creators are not fun. It's probably not as noticeable with smaller apps, but it becomes really apparent as your apps get larger and more complex.

Writing middleware to handle async units of work and letting component lifecycle drive the actions helps keeps things compartmentalized, easily testable, and feels much easier to reason about. All your action creators suddenly become very simple, and the event loop is no longer this alien entity. It's one of those things where Dan Abramov has said he regrets making redux-thunk and instead promotes writing middleware, people will say it can be better, but you might not ever truly see how/why it's better until you experience pain and then go through the exercise of rewriting.

Long story short: if you find it difficult to reason about your app's state management, unit testing becomes a nightmare, and/or you're getting scaling headaches give it a try. If thunks are working for you and you haven't spent time thinking about better ways of doing things while in the shower, don't worry about it.

Can you post an example of this?

# ¿ Mar 12, 2017 15:20

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

Helicity posted:

It's a lot of churn that is even more apparent when you have experience in a more stable ecosystem like Java, Python, or C# (even including Core CLR). One problem is the tendency towards modular architectures that make documenting the interaction between modules critical, but most authors consider that outside the scope of their concerns. The other problem is that documentation in general is poor for many of these projects, so blog posts and tweets are useful sources of information but become outdated very quickly. A React boilerplate from 2015 can be unusable in 2017, for example. Steps are being made, so there's hope - Redux and Webpack both got healthy updates to their documentation.

Dismissing frustration with the ecosystem as a fear of learning isn't fair. I'd rather solve interesting problems or play with Haskell/Kubernetes/whatever than figuring out yet another modular build tool for JS.

That's fair, and definitely an angle I hadn't considered. Most of the griping I've seen comes from a place of "I can just make that todo list example app with jQuery."

quote:

...Middleware code

This is really cool. My thunks are definitely looking like your first example there. I've been thinking about making the move to Sagas for my next project but maybe I'll try this middleware approach instead. I think something about middleware has made me just ignore it after I get my initial app set up, like it's a place for general plugins and extensions and not application code. Thanks for sharing!

# ¿ Mar 13, 2017 05:01

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

I've been working at the same company for over ten years. I really love my company but the fantasy of making a clean break from all the lovely code that I've shipped over the past decade is definitely nice sometimes.

# ¿ Apr 2, 2017 00:50

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

I have had cases where I've put two React apps on the same page, and it's because I'm trying to force-fit React into a legacy Rails site that I'm adding features to. I don't think it's something I would ever do if I was starting from scratch and had control over my stack.

# ¿ May 1, 2017 19:09

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

What's everyone using for error tracking? I've seen Bugsnag mentioned a few times, but for a decent sized team it's not cheap. Anyone using Sentry, or something else?

# ¿ May 3, 2017 04:15

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

Doesn't everyone just use eslint?

# ¿ May 6, 2017 15:57

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

Eslint has some auto fix stuff now I think.

# ¿ May 7, 2017 05:37

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

Is anyone out there making a living or any side cash freelancing this sort of work? I'd like to bring in some extra money and I consider myself a pretty solid full stack but mainly front end developer (I do it full time for an agency) but freelance work seems to be Wordpress as far as the eye can see.

# ¿ Jun 3, 2017 15:04

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

Are there any downsides to TS if you're primarily working with React? I recall hearing something about TS not being able to do functional components until like 2 months after they dropped, but that was a long time ago. Is that kind of lag time still common? Do you ever run into issues with third party libraries or components?

# ¿ Jun 12, 2017 15:42

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

What kinds of tests would you want to see for a simple open source React Component? I wrote a small wrapper for an existing JS carousel plugin, should I just be testing whether the props get forwarded as options to the plugin?

# ¿ Jun 13, 2017 19:24

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

10+ years ago when I was a young and stupid Ruby developer my goal was always to write the sickest one-liners I could, with no regard for character limits. God I was a dumbass.

# ¿ Jun 14, 2017 15:09

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

What is C# typically used for? Is it microsoft stack stuff? Web dev? I've never touched it but everyone speaks so highly of it.

# ¿ Jun 16, 2017 03:48

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

Love Stole the Day posted:

Sorry for this terribly stupid question: what does a successful resume (i.e. you can get hired with this) look like for someone trying to get a job with some 2nd/3rd tier company in this field?

I do some of the hiring at the small agency where I work. Resume should include languages you have experience with, previous relevant jobs, and not look like garbage. It should also have a link to your GitHub, personal website, or something that shows you actually know how to to write code. You won't get hired from your resume alone, our process is a short phone interview (to confirm you are who you say you are and can carry on a normal conversation like a functioning human being) followed by a technical interview with questions about the language(s) that you want to write for us (no white boarding or algorithms, more like "what is the value of this in this context"), and then an interview with me where we talk about the business side of programming (testing, best practices, working in teams, dealing with scope creep, dealing with clients, managing deadlines, etc.)

Basically what we're looking to find out is 1. can you code? 2. can you code in a semi-professional environment as part of a team?

edit: 3. also: are you some kind of weirdo that no one will want to work with and that we can't bring to client meetings

prom candy fucked around with this message at 21:17 on Jun 18, 2017

# ¿ Jun 18, 2017 16:07

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

a hot gujju bhabhi posted:

Just so we're clear, this is not at all a dumb question. You're being realistic for the level of experience you have - for a junior developer position you often don't need specific experience or degrees, just an ability to demonstrate understanding of the language and a willingness to learn.

Also, gotta emphasize this again, don't be a big weirdo that nobody wants to work with. I've hired less experienced coders over more experienced ones if they seemed like a better overall team fit. You can teach technique, you can't teach the intangibles and having a group of people that actually like each other goes a long way.

# ¿ Jun 19, 2017 06:07

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

I know javascript, es6, es7, and coffeescript.

# ¿ Jun 21, 2017 04:28

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

Gildiss posted:

Forgetting jQuery?

I use prototype and scriptaculous. I'm not just going to jump on every stupid flash in the pan hipster library that comes out.

# ¿ Jun 21, 2017 05:43

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

Maybe people who built Angular projects have quit their jobs to go work on React projects?

# ¿ Jun 21, 2017 19:57

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

I just started using VS code this week after year and years with sublime. It seems good, the code completion is really nice.

# ¿ Jun 27, 2017 05:42

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

Does anyone know of a good open source React + TypeScript project (and maybe Redux) project I can take a look at? Also is there a well-regarded source for style/linter settings like airbnb is for ES6?

# ¿ Jun 28, 2017 13:54

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

I have honestly never felt like the speed at which I can put down code is my bottleneck when developing software. The amount of time I lose from taking my right hand off the keyboard and putting it on the mouse pales in comparison to the time I spend thinking about how I want to approach the next problem. Some of the biggest tedious time sinks for me are things like remembering what my colour variables in SCSS are called, or what props a component I wrote takes, so I'm finding VS Code is actually really improving my speed in that sense, because I don't have to switch around between files to keep things straight. I tried to switch to vim about a year ago because I was trying to make more use of tools like vagrant and wanted to just edit directly on the VM but it felt like a massive step backwards for me, it would take me ten years to make up all the productivity I was losing in trying to switch.

# ¿ Jun 29, 2017 14:55

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

Yeah on the npm modules I've published I only push the lib directory, which is built with Babel. The src folder goes into .npmignore. Rather than opening the node_modules folder you should check out the project on GitHub.

# ¿ Jul 2, 2017 15:05

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

How the heck do you dev on VMs or docker? Unless you're vim user it seems like you're stuck using one of 3 file sync methods, none of which really work well if you want hot reloading and all that.

# ¿ Jul 3, 2017 17:32

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

Lumpy posted:

You can have folders in the VM be mounted on your host machine, so you can edit "server" files locally with whatever you want to edit them with. Which for me is MacVim (oh god not another editor derail...)

This is the part I couldn't get working right. One strategy wouldn't actually send file system events, another kept losing sync, etc. I eventually just gave up and went back to doing local development.

# ¿ Jul 3, 2017 21:18

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

Helicity posted:

Redux, for all the poo poo I give it, has done a lot for Javascript - it brought functional concepts and event sourcing to the forefront of the mainstream, in that many JS developers have a better handle on these topics than backend developers, which is very cool/strange. I'm a little surprised that Ramda, RxJS, and the like haven't taken off more.

Dan's love of JS is contagious

# ¿ Jul 12, 2017 02:32

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

Why not eslint's autofix?

# ¿ Jul 12, 2017 16:45

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

thunks have been good to me for the most part, I've built a few redux apps and haven't felt the need to switch over to sagas or custom middleware. Maybe my apps aren't that complex though.

# ¿ Jul 13, 2017 04:06

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

Seconding JavaScript or TypeScript. Hiring and retention are easier if you use popular tools.

# ¿ Jul 14, 2017 05:50

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

PRADA SLUT posted:

How do you make individual <th> a background color using CSS? I have a CSS file that notes style elements for the whole table, but is there a way to make individual cells a certain background color, without wrapping each of them in a div?

Give them a class.

# ¿ Jul 17, 2017 17:38

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

PRADA SLUT posted:

<th><div class="myClass">Text</div></th>

For each one?

E: when the class is defined with background-color, it leaves a table with a "color stripe", respecting the text padding, instead of filling the entire cell and ignoring the padding.

You can put a class on the th element itself, you don't need a div.

# ¿ Jul 17, 2017 18:38

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

So should I be putting time into learning Cycle.js/redux-cycles/FRP?

# ¿ Jul 19, 2017 14:02

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

I'm not looking for a new job necessarily, just looking to stay current and have an easier/more fun time building apps.

# ¿ Jul 19, 2017 15:46

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

HaB posted:

code:

<div class="ui eight column grid">

Maintaining this kind of code is a nightmare. Stuff like this is great for getting stuff online quickly, but it's not scalable.

# ¿ Jul 20, 2017 18:59

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

Your class names should describe what something is, not how it looks. When you have to make changes across lots of different areas of a site it makes it really difficult if everything has a ton of class names, and even more so when it's hard to tell which class names are related to which larger overall concept.

In my experience, systems like BEM are way better for creating CSS that scales. Your HTML says what things are, your CSS determines how they look.

# ¿ Jul 20, 2017 19:39

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

We had a developer who did all that stuff too, and it was me. This is all stuff that seems like a really great idea until you have to scale it or maintain it.

# ¿ Jul 20, 2017 20:58

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

I use flexbox all the time but I wouldn't write

code:

<div class="ui grid outer">
  <div class="ui columns four">An image</div>
  <div class="ui columns eight">Some info</div>
</div>

I would write

code:

<div class="article">
  <div class="article__image">An image</div>
  <div class="article__info">Some info</div>
</div>

# ¿ Jul 21, 2017 00:54

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

Maybe we just work on different projects. Over the past 12 years or so I've build hundreds of websites, many small, some massive. In an agency setting, the number one rule when developing any kind of software is that business requirements WILL change. You rag on "snowflake styles" as if no designer has ever said "hey I need the third article on the home page to be different than everything else."

BEM class names are pretty ugly, it's true, but they also convey a ton of meaning. The beautiful thing about having a div like "article__image" is you know exactly what it is, where it belongs, where to find it in your CSS, and what CSS rules are affecting its design. If you rely on using class composition to style things you can end up with conflicting styles (the classic "why is this text red" problem.) If I go into a project and I need to edit styles for .article_image, I open _article.scss and everything I need to know is right there. I can confidently change _article.scss and know that I'm not going to affect some other component.

In terms of repetition, this is solved easily using mixins or extensions with SASS, or whatever your preferred CSS preprocessor is.

code:

.article {
  padding: $spacing-sm;

  @include breakpoint($medium) {
    @include grid-container;
  }
}

.article__image {
  width: 100%;
  margin-bottom: $spacing-md;

  @include breakpoint($medium) {
    @include grid-columns-4;
    margin-bottom: 0;
  }
}

.article__info {
  width: 100%;
  
  @include breakpoint($medium) {
    @include grid-columns-8;
  }
}

Now if I have articles littered throughout my code base and I want to change them to be 5 and 7 columns, or I don't want them to break into a grid until the $large breakpoint, I only have to edit one file, and I can do so confidently knowing I'm only affecting instances of article. If I used your case of calling my subclasses just "image" and "info" how do I make targeted changes if I don't want to also affect other, non-article places where I want to use the "image" class? A bunch of nesting? Nooo thank you, that becomes hard to read and hard to find really fast. If I truly have a global "image" then it can become its own block:

code:

<div class="article">
  <div class="article__image">
    <div class="image">
    </div>
  </div>
</div>

This might seem gross to you, but the important thing is when another developer is onboarded or I come back to this project after working on other stuff for a year it's instantly obvious what's going on. "article" is a block and all of its styles can be found in _article.scss. "article__image" is responsible for positioning "image" within an article block. "image" is its own global block that's used elsewhere in the site, and its styles can be found in _image.scss.

In your example you have classes like "eight wide column" and "four wide column." What happens when you need to radically alter the presentation depending on the size of the device the user is using? In my article example it's easy for me to say, okay on mobile-ish sizes the image and the info stack on top of one another, on a small tablet maybe we go 50/50, and then everything up from there is 30/70. Your HTML class composition is declaring how it looks, not what it is. In a world of RWD that's not really great unless you're okay with your grid ALWAYS changing in the exact same way, at the exact same breakpoints. My designers are not okay with that. So then what's the class composition solution? "eight wide column sm-six md-ten"? Ack!

If you've never maintained CSS on a huge website, never had to make changes to a project that you weren't the original developer on, or generally don't deal with these kinds of problems I can see how BEM would seem insane to you, but for us it's been an absolutely massive leap in productivity and maintenance.

# ¿ Jul 21, 2017 14:12

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

The reason I like block__element--modifier is because it's a janky way to manage namespacing. I think all this goes away when whatever CSS in JS solution comes out as the clear winner but for now if you have ".article.image" and ".profile.image" there's a risk of editing the styles for .article > .image and accidentally changing .profile > .image in the process. I would rather write longer class names than deal with ambiguity.

# ¿ Jul 21, 2017 18:43

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 09:10

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

Grunt

# ¿ Jul 25, 2017 05:06

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

«‹›14 »