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

«‹›4 »

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

No need to test the component you are wrapping, test that the wrapped component is rendered and receives the props you expect it to. Then test whatever else your wrapper is supposed to do.

# ¿ Jun 13, 2017 19:27

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 09:37

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

Yeah but the Javascript community has gone nuts. I think JS is the best language there is, there I said it. I haven't tried all of them, but the feature set, how fast it is, and how widely utilisable a .js file is across platforms and devices cannot be ignored. There are a million ways to compile things into JS if you don't like using ES2015+, but even if you do, it's really really good.

Where things go wrong is within the community. When it started it made sense because JS was terrible, so there were a million libraries that made JS unrecognisable. Now, when I look at a pile of new fangled library, framework, and obfuscation infused JS code my eyes roll into the back of my head. You don't need all that crap. The language does everything you need out of the box.

Stop re-inventing the language and use the language, internet. Stop introducing libraries that enable you to write incredibly confusing, slow, "functional only" crap. Stop trying to warp it, it's great the way it has become. I'm so thankful the dark lords who introduce new language features ignore 99% of it.

# ¿ Jun 14, 2017 19:44

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

Thermopyle posted:

This post ties me in knots because I strongly agree with it and strongly disagree with it.

Like, yeah there's too many developers chasing too many new things. On the other hand there's a ton of very useful libraries that you're just being a masochist or someone stuck in their ways for not using. And picking functional programming as an example of what you're on about is weird as functional programming is cool and good and has nothing to do with chasing new and shiny.

The problem isn't functional programming, functional programming changed my life in some small ways. But it is to be used in moderation, not for everything.

Stuck in your ways, imo, is using a hundred libraries for everything regardless that they are new libraries. That is how JS has been done for a very long time and it simply is not needed anymore. It takes effort to learn how to write raw JS that doesn't require constant never ending fiddling to keep working.

# ¿ Jun 14, 2017 20:22

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

a hot gujju bhabhi posted:

Does this include C# because wtf I want whatever you've been smoking.

I got a dime bag of TypeScript, it's JavaScript's C#

# ¿ Jun 15, 2017 19:40

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

smackfu posted:

It really annoys me that node-sass, the defacto sass handler, uses a native C library to do the actual work. It means that package breaks more than all our other ones combined.

Sass doesn't have any native JavaScript implementation, that has been a strike against it for a long time in Node development. Most people I know of that are aware of this issue switched to less. The issue I have with less is that for some ungodly reason there is no included file watcher.

Also if you want any sort of basic css compatibility or, well, anything really. You need additional packages. Lately I've been ruthlessly feeling out Myth which is based instead on the actual css spec.

Nolgthorn fucked around with this message at 16:11 on Jul 15, 2017

# ¿ Jul 15, 2017 16:08

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

Some other-totally-better-than-Webpack.js: https://rollupjs.org/

Simply bundles javascript es2015 imports, simply. It's like abreath of fresh air. I get to just build websites again, I never needed a built-in development environment / giant config files / compiled html. Just bundle the god drat imports into one file so I can program using modules and use them.

# ¿ Jul 24, 2017 21:16

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

The only important thing Webpack does, serves the same purpose as Rollup. Webpack is a monolithic bloated mess that tries to do 1000 different things I don't want. I suppose other people do want that, and in that case I can see what you mean that they aren't the same tool.

For me they're the same tool.

# ¿ Jul 24, 2017 22:39

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

Hello fellow coding hipsters.

It has finally happened. I am using a component based framework called Vue willingly, not just because I have to use such a thing for work either. I started developing as I always do in my naked development environment using Typescript and nothing. But this time I was building a true single page app powered by Websockets and I couldn't get my head wrapped around not reloading the page for logged in/logged out state.

You win, components. You win. Can I apply for the handlebar moustache here, what kind of delivery time are we looking at?

# ¿ Sep 8, 2017 19:06

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

Pollyanna posted:

How do you verify higher order/chained functions in Sinon+Enzyme? I have function f which takes functions g and h, and I need to verify that f performs g(h()). I tried making g and h spies, and checking `g.calledOn(h)` and `g.calledWith(h)`, but neither seem to work.

Edit: I am diving further into unit testing Redux containers with Sinon+Enzyme and wow unit testing front-end stuff is some dire poo poo.

It is likely to me that h() is returning a generated object, or something like that which does not === your real test result. Although the data within might be identical between the objects the reference is different.

# ¿ Sep 8, 2017 19:12

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

Love Stole the Day posted:

Can anyone show me an example or two of what a portfolio looks like for applying to front end jobs? Because job searching is like a black hole: resume goes in, nothing comes out.

I've had success with a paragraph long comma separated list of technologies and things I know. Followed by a short thing explaining how much professional experience I have. Followed by standard resume fare like jobs and for each listing what I learned.

Proving that I'm not a barely functional autist in the interview is where it falls apart.

# ¿ Sep 8, 2017 19:20

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

The Merkinman posted:

Has anyone read this article comparing Angular, React, and Vue? For those familiar with those frameworks, what are your thoughts?
https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

Vue is newer than React and has a lot of neat things to offer. I like its template syntax, I like that I don't have to use jsx, although if I did want to use jsx it is not super easy to do it. My experience with React/Redux has been that Redux is a nightmare. Facebook seems to have acknowledged this in the form of Immutable.js which is a horrendous library and rather than making the situation better, just pollutes a code base irreprably.

Vue has a sweet "reactive" store available as an extension which is by comparison an absolute pleasure to use. However, nothing is tying you to Redux in React, it has a Vue-similar library you can use instead.

I've not used Angular. But it uses Typescript which is awesome.

# ¿ Sep 23, 2017 17:53

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

I have a nitpick about Vue though. In my components I have to assign them a name.

code:

export default {
    name: 'my-component'
};

And then when I want to use it I use that name.

code:

<div>
    <my-component />
    <my-component />
    <my-component />
</div>

But for that to work I have to import the file and specify it in the parent component.

code:

import MyComponent from './MyComponent';

export default {
    name: 'my-parent-component',
    components: { MyComponent }
}

I don't like how the import has a different name, slightly, than the actual name of the component. Within the parent component I don't know exactly what the name of my child component is. Furthermore, why is `components` an object? Why is the key `MyComponent`?

It feels like I shouldn't need to define a name in the component. And it feels like I should be able to use it in my parent component like so.

code:

import MyComponent from './MyComponent';

export default {
    name: 'my-parent-component',
    components: {
        'my-component': MyComponent
    }
}

# ¿ Sep 23, 2017 18:14

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

Thermopyle posted:

Also, redux is awesome.

Mutable state is awesome. I cannot willingly go back ever. `mobx` is the new kid on the block redux alt.

Nolgthorn fucked around with this message at 23:25 on Sep 23, 2017

# ¿ Sep 23, 2017 23:20

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

Odette posted:

What the gently caress are you smoking?

I'm smoking vuex since quitting redux, I still use some redux from time to time for work but I'm quitting that too.

# ¿ Sep 24, 2017 11:54

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

Grump posted:

Thanks. For some reason, my brain always thinks writing functions inline is bad

In this case it shouldn't matter. But you could:

code:

class App extends React.Component{
  constructor() {
    super();
    this._onChange = this._onChange.bind(this);
  }

  _onChange (e) {
    this.onSelectChange(e, otherArg);
  }

  ... etc

  render(){
     return(
       <select onChange={this._onChange}>
         <option value='1'>1</option>
         <option value='2'>2</option>
         <option value='3'>3</option>
       </select>
     )  
  }
}

You should do that for `ref=` because react doesn't handle it very well, it would have to unassign the reference and then assign it again on every rerender, because the function changes.

# ¿ Sep 24, 2017 13:03

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

Bind returns a new reference, it performs essentially the same thing as an inline function in this case.

# ¿ Sep 24, 2017 13:16

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

I had a mouseover event instead of mouseenter and I didn't notice because in Vuex it had 0 performance overhead.

Having access to `this.$store` `this.$getters` `this.$route` `this.$socket` etc etc all the time is great. When I wanna update something in the store I just change it. I don't need `mapStateToProps` or `mapDispatchToProps`. The only "problem" per say is that you cannot do key assignment.

code:

this.$store.state.messages[myKey] = myMessage;

Needs to be.

code:

Vue.set(this.$store.state.messages, myKey, myMessage);

Otherwise Vuex has no way of knowing the object changed apparently. Similar with delete. So that could cause an issue for the not careful. Still, I don't think I'd give up mutable state now that I've tried this stuff it's too easy and too performant.

# ¿ Sep 25, 2017 23:40

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

You gotta set the header manually.

https://coderseye.com/2007/how-to-do-http-basic-auth-in-ajax.html

* get base64.js

code:

function make_base_auth(user, password) {
  var tok = user + ':' + pass;
  var hash = Base64.encode(tok);
  return "Basic " + hash;
}

const auth = make_basic_auth('me', 'mypassword');
const url = 'http://example.com';

xml = new XMLHttpRequest();
xml.setRequestHeader('Authorization', auth);
xml.open('GET', url);

# ¿ Sep 26, 2017 00:37

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

See the problem with front end javascript frameworks these days is evangelicalism let me tell you about -

# ¿ Sep 26, 2017 19:32

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

I saw this in a movie once I think it was Superman II.

# ¿ Sep 27, 2017 10:35

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

I have recently worked on a overly complex Redux app. The big benefit is still a little bit elusive to me but I think something that's really helpful is nested selectors. So that I can get some complicated data and then use it to make more complicated data, then just have reliable derived attributes from a single source of truth.

Everyone praises it for making sure no developers accidentally mutate the state but I think that's a bit of a underwhelming benefit. Hopefully the team you are working with aren't re-assigning parameters passed into functions.

A good linter could fix that.

I guess I also don't really know what all the fuss is about, because the first benefit is a bit like regular programming and the second benefit doesn't overcome the added complexity in my opinion.

# ¿ Sep 28, 2017 19:57

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

const unless you need to change it.

# ¿ Sep 30, 2017 16:45

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

var ignores block scope and is handled delicately in compiled es5 through naming tricks.

Once you get used to let/const, it becomes easy to fall victim to var gotchas. in any new code, or code that I am changing, vars are one of the first things to go.

# ¿ Sep 30, 2017 18:41

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

Typescript has readonly casting, but nothing prevents you from re-assigning the reference and then mutating. I kinda think Typescript should introduce immutable objects that seems like the logical place to put it.

# ¿ Oct 2, 2017 16:40

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

Font icons are awesome.

code:

i.icon {
  display: block;
  height: 20px;
  width: 20px;
  line-height: 20px;
  text-align: center;
}

# ¿ Oct 4, 2017 00:18

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

but... i posted how to get it exact... you mean its literal pixel-perfect size and positioning inside the pixel perfect square?

# ¿ Oct 4, 2017 16:58

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

Typescript is similar to C#. I tried using Typescript for server code and eventually just gave up. Server code is generally npm module heavy requiring many @types npm modules to match. Server code is also in my experience not all that complex, compared to a client side app so value is reduced.

There's also the compilation question, which is a bit of a turn off. Because server code can use the latest Javascript features without a compiler.

There is an Express.js @types library though.

# ¿ Oct 5, 2017 09:15

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

ModeSix posted:

To be fair this is the front-end thread so he's likely never touched the backend beyond express (which honestly should be the absolute last choice for a backend if you ask me) or some other JS flavour of the week. Because anyone that says that hasn't really done backend work.

When the backend "just works" it appears really simple to the consumer.

When I make that statement I am ignoring devops, which thanks to lots of really smart people isn't as complicated as it used to be. Load balancing and sharding and stuff like that is still pretty complicated.

I'm talking about just the code. There are so many complex well tested frameworks/modules/etc out there it's all relatively straight forward, I mean, largely... if you need to process data from a satellite or something like that then to me we're talking about something else. You'd likely abstract that into a separate microservice or at least a module.

Then you just piece it together. It's all encapsulated in a reliable environment. It's like lego at that point.

Client side development on the other hand is the drat wild west.

# ¿ Oct 5, 2017 16:57

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

Helicity posted:

The DOM API is hot garbage - you needed jQuery just to standardize between the browsers, you need transpilation to use any current features that make dev easier while still supporting idiots using IE 10/11, and you need things like Angular and React just to deal with how incredibly inefficient it is the update the DOM.

It's made worse by Mozilla being altruistic, Google chasing web/ad domination, and Apple hoping the web dies in favor of walled garden apps for consuming content.

If people didn't flip their poo poo about Microsoft in the 90s we might all be using a standardized browser with deep .NET integration and sane DRM solutions. We stopped Microsoft from taking over the world, but now we have Google, Apple, and Facebook doing the same poo poo they did. It's an interesting "what if" to consider.

jQuery is an example of some of the litter on the floor of any website shop.

You did need it, a really long time ago, and people are still using it. Combining it even, with React Redux and every other monolithic piece of technology under the sun. So you end up with websites using MBs of javascript that runs slow and is a nightmare to maintain.

Updating the dom isn't inefficient it's super. If you update a whole bunch of things the browser is smart enough to optimise, to a fault. Where you have to build in hacks so that your ui details aren't optimised out of the rendering queue.

React/Redux isn't really smooth. Every update to the store runs every single mapStateToProps in the entire application. So then you end up caching selectors, not helpful for performance.

Spent a bunch of money on .Net courses and as soon as I was done never touched any of those things again. Everything in .Net land was closed source, you had to either pay for things as simple as a dropdown with timezones in it, or you had to build the component yourself which wasn't really easy. It was licensing out the butt.

I like client side coding but something has to be done about every developer in the world having a completely different vantage on it.

# ¿ Oct 6, 2017 21:47

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

I like to have a bunch of iTerm instances running on another screen. I never use the console in VS Code. Although, I'd love to be able to run a specific test or test file from the editor that would be nice.

# ¿ Oct 8, 2017 17:33

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

I am building a Vue/Vuex app and have reached the stage where I need; clicking on some things trigger popovers that have all kinds of different stuff in them.

For example, clicking the trash can on a row of a list of items should trigger a popover with "Are you sure blah blah blah deleted and and xyz other related stuff?" with Delete and Cancel buttons. Some other popovers would have more complicated content.

How can I set something like that up, so that preferably near the App route I can render it?

code:

<div id="app">
    <page-header />
    <router-view />
    <page-footer />
</div>

Under the `page-footer` mayhaps.

I'm thinking I would put it into the store such as...

code:

{
    popover: {
        type: undefined,
        data: {}
    }
}

That way I could render a different component depending on the `type`, which I would treat as an enum. And I'd have any extra data I needed by replacing the `data` object. Does that sound about right for how I should approach this challenge? Is there an established best practice for this type of thing.

# ¿ Oct 9, 2017 01:38

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

The documentation advises that I use the store if I want to do something in a parent or a sibling. I could render the popovers in the dom directly where the button is that opens them, I suppose and I can use position fixed.

But that doesn't feel right either.

# ¿ Oct 9, 2017 02:01

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

C# is super useful because it's a good language in general.

I think my perception of C# in the browser was that it was essentially just another layer of abstraction on top of what everybody else was doing. It being closed source didn't help their case but it wasn't the biggest problem that I had.

# ¿ Oct 9, 2017 17:59

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

Best practice question about Vue js.

When I have a list of users, and I want to pass a bunch of props at once, is it better to pass a single prop as an object, a single prop as an id, all of the props using `v-bind`, or each prop I need individually.

code:

<user-item v-for="user of users" :key="user.id" v-bind="user" />

// or

<user-item v-for="user of users" :key="user.id" :user="user" />

// or

<user-item v-for="user of users" :key="user.id" :id="user.id" />

// or

<user-item v-for="user of users" :key="user.id"
  :id="user.id"
  :name="user.name"
  :email="user.email"
  :created-at="user.createdAt"
  ...ETCETC />

Lets say I need like 10 props in total...

If all I pass is the `id` then inside the `user-item` component I'd select each attribute I need from the store.

e:

Going with the `:user="user"` option, with `props: { user: { type: Object, required: true } }` and although I'm not sure about long term it is working for me well right now.

Nolgthorn fucked around with this message at 17:26 on Oct 10, 2017

# ¿ Oct 10, 2017 16:17

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

Skandranon posted:

What is wrong with passing in the user object? You have a component that seems to be built around the concept. There's nothing wrong with a component that is purpose built to display a specific object.

In the React world that was bad practice because of the way it optimised re-renders. I don't think it's an issue in Vue... at least from what I can tell so far. But that's why I was asking.

# ¿ Oct 11, 2017 21:31

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

I'm starting to think form elements should be abolished in favour of custom JS based solutions. I'd be surprised if there wasn't a lib out there that gave you the default behaviour of form inputs as a starting point.

Nolgthorn fucked around with this message at 20:27 on Oct 16, 2017

# ¿ Oct 16, 2017 20:23

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

Helicity posted:

Forms were some of the most time-consuming and bug prone things I've seen done in Angular or React. If a designer ever brings up writing your own form logic, distract them with something shiny and run. The ROI is seriously not there.

Hey man don't stress see look I'm practically almost done. Get one of the interns to write a test or two and don't try it in any other browsers and lets move on to something else.

code:

<template>
<div class="decimal-number">
    <span>{{ number }}</span>
    <a @click.prevent="goUp">+</a>
    <a @click.prevent="goDown">-</a>
</div>
</template>

<script>
export default {
    name: 'decimal-number',
    data () {
        return { number: 0.1 };
    },
    methods: {
        goUp () {
            this.number += 1;
        },
        goDown () {
            this.number -= 1;
        }
    }
};
</script>

Don't even give it another thought.

# ¿ Oct 17, 2017 04:39

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

Pollyanna posted:

Related question: we�ve got some code for interpreting input field strings as integers, two-place floats, etc. This was all made in-house. This seems like something that is best handled by an external library that�s well tested and commonly used, but I have trouble reconciling that idea with the stereotypical �use a bunch of modules for everything� approach ala padLeft. I�ve heard that I don�t want to fall into that hole.

Is it forgivable to use a number/currency parsing and formatting library such as accounting.js, or is it better to write your own thing?

Just for numbers, I'd do it myself.

https://www.w3schools.com/jsref/jsref_tofixed.asp https://www.w3schools.com/jsref/jsref_parsefloat.asp

code:

let myFloat = 3.366666;
myFloat.toFixed(2); // "3.37"

let userInput = parseFloat("3.37");
if (isNaN(userInput)) throw new Error("Invalid input");

Don't test it and don't tell anyone.

edit:

Unless we're talking about server code. Then I would feel much more comfortable using an accounting library of some sort, because for one thing it's hidden, but also there might be more important logic there.

Something feels superficial to me about client side coding, I don't feel like the logic there matters as much.

Nolgthorn fucked around with this message at 21:34 on Oct 18, 2017

# ¿ Oct 18, 2017 21:28

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

My application has reached the stage where I need to send html emails.

So I'm experimenting with Mjml the issue I'm having is that it seems to use a lot of padding around every `mj-column` and every `mj-section` and every everything.

My emails are data heavy, where I need basically small headers, squares with blurbs in them, compact, links on everything. I really need a more data-centric look. Am I better off reading a comprehensive book about how to structure html emails? If I don't care about supporting every email client since the beginning of time do I need to worry about it?

Maybe I can just write a template that uses normal html and be done with it these days.

# ¿ Oct 18, 2017 21:45

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 09:37

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

Grump posted:

I try to import and get ''no default export for this component'

Typescript is harder the more 3rd party stuff you use. If a package was built with Typescript the language is pretty cool that it doesn't need definitions and just works. But I had a similar problem as you. Typescript doesn't handle globals basically at all. So if you have a library that just defines a bunch of stuff on `window`, you can trick Typescript into performing an "import" but not multiple imports.

There's a workaround described here.

https://github.com/rollup/rollup/issues/1476#issuecomment-314033953

On second thought that's probably a separate issue from what you meant.

# ¿ Oct 19, 2017 14:28

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

«‹›4 »