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 »

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

Inacio posted:

this thing at the bottom?

if so,
code:
#root > div >div {
    display: none;
}
you can probably be more specific than that if it breaks something else

No, I get

and that's randomly generated :|

# ? Feb 3, 2020 20:20

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 09:08

The Fool: Oct 16, 2003

that modal and the credential picker are always the last two divs if that helps at all
the credential picker is always last
the modal is last if the credential picker is not present, second to last if it is

e: and the credential picker has a consistent id

# ? Feb 3, 2020 20:24

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

I was worried the nth-of-type would be too broad, but it does seem to work without breaking anything

# ? Feb 3, 2020 21:50

The Fool: Oct 16, 2003

afaict the credential picker and modal are the only divs that appear outside of the #root div

# ? Feb 3, 2020 21:57

Dominoes: Sep 20, 2007

Inacio posted:

this thing at the bottom?

if so,
code:
#root > div >div {
    display: none;
}
you can probably be more specific than that if it breaks something else

I'm working on a browser plugin that aims to block things like this. It's a tough task on multiple levels, but the general solution looks like a collection of approaches. In this case if there's no obvious cues in the class list, you might have to parse the text and identify words like "free", and phrases like "when you create a free" to increase confidence it's self-serving (as opposed to quality-increasing) content. Unfortunately, I'm currently blocked on a problem I don't understand, that causes the plugin only to work when loaded over already-loaded pages.

# ? Feb 3, 2020 23:05

Dominoes: Sep 20, 2007

rujasu posted:

Having been a programming tutor for a year when I was in college, I will say that for a lot of people, yeah it absolutely is an alien thing that they just don't get.

To be clear, this isn't about castes; there are plenty of people employed as coders who can't code, and plenty of people employed as designers who can code or who could potentially learn to code. But "just do it" isn't realistic for everyone. Plenty of people just can't learn to code, or at least can't do so easily.

Likely true for many people, especially older ones who didn't develop math skills etc in their teens/20s. I encourage people who don't have this type of limitation to expand their knowledge base; it's easy to confine your skill set based on self-created barriers that vanish upon a close inspection, or new perspective.

# ? Feb 3, 2020 23:08

marumaru: May 20, 2013

it actually gets even easier: if you use ublock origin (you DO use ubo, right?) it only takes :has-text

https://github.com/gorhill/uBlock/wiki/Procedural-cosmetic-filters

totally forgot about that.

# ? Feb 3, 2020 23:10

Vincent Valentine: Feb 28, 2006; Murdertime

CSS in 2030: people new to the industry ask what it means and you have to say "it stands for cascading stylesheets. It neither Cascades nor is it a stylesheet, it's a legacy naming scheme."

# ? Feb 3, 2020 23:21

marumaru: May 20, 2013

"flexbox is a travesty. it's taking the craftsmanship out of building websites"
- someone, probably

# ? Feb 3, 2020 23:26

Cheen: Apr 17, 2005

If you're spinning up a new project, what requirements would you have to elect to use case grid. Can you mix flex and grid easily?

# ? Feb 3, 2020 23:40

Dominoes: Sep 20, 2007

Cheen posted:

Can you mix flex and grid easily?

Yep; they're BFFs.

# ? Feb 3, 2020 23:47

The Fool: Oct 16, 2003

Can someone tell me why my border-bottom-color is getting overridden?

# ? Feb 3, 2020 23:48

Dominoes: Sep 20, 2007

Is the .menu li border-bottom overriding it? What if you use border-bottom-style instead of border-bottom to set solid?

# ? Feb 3, 2020 23:52

The Fool: Oct 16, 2003

no, that's where I'm setting the teal color, and it's getting displayed at #757575 for some reason

there is literally nothing else styling the li elements, even outside the .menu class.

if it helps, I am setting the font color to #757575 in the body, but I have a div that sets border-left somewhere else and it doesn't have this problem.

e: border-bottom-style worked

# ? Feb 3, 2020 23:54

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

Cheen posted:

If you're spinning up a new project, what requirements would you have to elect to use case grid. Can you mix flex and grid easily?

_{(from https://caniuse.com/#feat=css-grid)}

That number has to be high enough to satisfy the people in charge of such things.

If the person who is in charge of such things is me, the number is high enough.

# ? Feb 4, 2020 01:02

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

Thermopyle posted:

_{(from https://caniuse.com/#feat=css-grid)}

That number has to be high enough to satisfy the people in charge of such things.

If the person who is in charge of such things is me, the number is high enough.

But our Internet Explorer users :qq:

(there are CSS grid things IE doesn't support, even in the old syntax)

# ? Feb 4, 2020 01:37

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

Munkeymon posted:

No, I get

and that's randomly generated :|

I'm always surprised more people don't know this trick, but just use Googlebot as your user-agent.

This is particularly useful for sites that actually remove the article content from the DOM, because you know that they obviously serve the full article content to Google's bots since that's probably how you got there.

# ? Feb 5, 2020 12:06

Sistergodiva: Jan 3, 2006; I'm like you,
I have no shame.

I feel pretty good about my react knowledge but does anyone know a good book or course to improve my coding? I mean something more intermidiate. Doesn't have to be react specific but that's what I use today.

# ? Feb 8, 2020 12:48

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

Sistergodiva posted:

I feel pretty good about my react knowledge but does anyone know a good book or course to improve my coding? I mean something more intermidiate. Doesn't have to be react specific but that's what I use today.

One thing that immediately comes to mind for me is Airbnb's JavaScript styleguide: https://github.com/airbnb/javascript

I personally feel that their styleguide (implemented in my projects via the corresponding ESLint config) improved the general quality and readability of my code in projects I wrote afterwards; their explanations for all of the rules are well-thought out from their collective experiences with JS and so I found it easier to code to their standards since they seem as close to "practical best practices" as we have right now.

At the very least you'll probably pick up a JS gotcha or two that you can keep in mind to avoid in the future even if you don't follow these standards to the T.

# ? Feb 9, 2020 18:49

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

Sistergodiva posted:

I feel pretty good about my react knowledge but does anyone know a good book or course to improve my coding? I mean something more intermidiate. Doesn't have to be react specific but that's what I use today.

Read the blogs of Dan Abromov and Kent Dodds. They know a ton, think a lot about JS and React, and while they are not 100% infallible people who should be blindly followed, you will likely learn a lot of good stuff reading them.

# ? Feb 10, 2020 15:15

uncle blog: Nov 18, 2012

So, we have this React app. One of its pages is an EditCarPage where the user can edit stuff like the name or description of an existing car object. I want this same page to also function as the page where a user can create new car objects. Today we use React-Router and put the id of the given car in the url, and use React-Routers match prop to look up the given car object through a query based on the id and then fill in the form with the results. So I guess we could simply pass in a string like "new" in the url to indicate that we want to create a new object and leave the form blank. But my initial idea was to use a global context object where both the id of the car to be edited and a boolean determining whether it's a new or existing object.

Are there any pitfalls to one of the two methods I'm not seeing? Or otherwise a reason to choose one over the other?

# ? Feb 11, 2020 14:06

Love Stole the Day: Nov 4, 2012; Please give me free quality professional advice so I can be a baby about it and insult you

Every time I think I'm comfortable with a pattern or trick in Angular, I turn a corner and see that the rabbit hole goes another mile deeper.

NgRx stores and effects? Okay sure, but why stop there when you could create Selectors and ActionMaps.

But of course you won't be able to use switches in your reducers if you're using ActionMaps and Selectors, so to get around that we've reinvented them as SwitchMaps. Oh any by the way, did you know you could break out your state into Feature Selectors and and and

# ? Feb 11, 2020 14:25

Cheen: Apr 17, 2005

Love Stole the Day posted:

Every time I think I'm comfortable with a pattern or trick in Angular, I turn a corner and see that the rabbit hole goes another mile deeper.

NgRx stores and effects? Okay sure, but why stop there when you could create Selectors and ActionMaps.

But of course you won't be able to use switches in your reducers if you're using ActionMaps and Selectors, so to get around that we've reinvented them as SwitchMaps. Oh any by the way, did you know you could break out your state into Feature Selectors and and and

Same

# ? Feb 11, 2020 14:35

Queen Victorian: Feb 21, 2018

uncle blog posted:

Are there any pitfalls to one of the two methods I'm not seeing? Or otherwise a reason to choose one over the other?

edit: adding quote for clarity since some new posts came in while I was typing

I could be bungling this because I�m not particularly well versed in React Router, but I�ve built a bunch of these add/edit form modules in both jQuery (with homegrown router) and React (with React Router) but didn�t deal much with the router hookup.

We built them out as both add and edit from the get go, and the way the role was differentiated was to set an isEdit boolean and have the existing object as an optional parameter (forget which was dependent on which - at a different job now which is very low in forms so a bit removed from all this). If the object already exists, give the ID to the router (I think - I honestly don�t remember how the router was dealt with in terms of feeding it the right ID vs �add�), and use the boolean to determine whether to run the save or the update function, toggle form title and save/update button text, and disable any inputs that aren�t supposed to be editable once the object is created (if applicable).

Also, those forms always utilized a local duplicate of the real object (or local state in React) for taking all the input changes and then on save, committed for real. In the application at my current job, form changes are handled on the fly by prop-drilled factory action functions that all talk to the store all the time about everything, basically making submitting the form meaningless as long as you remain in the current session. It�s horrible and confusing UX and I can�t wait to rewrite it all.

Queen Victorian fucked around with this message at 14:40 on Feb 11, 2020

# ? Feb 11, 2020 14:37

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

uncle blog posted:

So, we have this React app. One of its pages is an EditCarPage where the user can edit stuff like the name or description of an existing car object. I want this same page to also function as the page where a user can create new car objects. Today we use React-Router and put the id of the given car in the url, and use React-Routers match prop to look up the given car object through a query based on the id and then fill in the form with the results. So I guess we could simply pass in a string like "new" in the url to indicate that we want to create a new object and leave the form blank. But my initial idea was to use a global context object where both the id of the car to be edited and a boolean determining whether it's a new or existing object.

Are there any pitfalls to one of the two methods I'm not seeing? Or otherwise a reason to choose one over the other?

The form that makes or edits a car shouldn't know or care if it's a new car or an existing car. It gets a car object with things that have some value, puts them in fields, and dutifully calls onChange handlers or whatever. The page that holds the form can see if there is a car ID present or not from the URL. If not, make an empty car and give it to the form. If there is a car ID, fetch it, then give the return (assuming it is found) to the form. Based on the presence of that existing ID you can then update or create a new car when the form is submitted. Adding a /new to the URL may be good from a usability / linking standpoint, but should be irrelevant to how things work.

# ? Feb 11, 2020 17:47

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

I'm trying to make a button component in Vue that will optionally request confirmation before emitting its click event. I have a modal component that I use for displaying modal messages and I'm going to use that for this as well. The problem is if I do this, I need the confirmation modal to be a part of the button template so I can show/hide it from within the button component.

I'm simplifying because my component is a mess from fiddling with it, but essentially this is what I've got in my Btn component:

code:

<template>
  <fragment>
    <button @click="onClick">Some button</button>
    <modal-confirmation v-show="isConfirming" />
  </fragment>
</template>

<script lang="ts">
import Vue from "vue";
import ModalConfirmation from "modal-confirmation.vue";

const BtnProps = Vue.extend({
  props: {
    confirm: Boolean
  }
});

@Component({
  components: {
    ModalConfirmation
  }
})
export default class Btn extends BtnProps {
  isConfirming: boolean = false;

  onClick(e) {
    if (this.confirm) {
      this.isConfirming = true;
    } else {
      this.$emit("click", e);
    }
  }
}
</script>

The problem I'm facing is that the modal confirmation itself also contains two Btn components for the "yes" or "no" buttons. So now I'm getting an error in the console saying for recursive components I need to set a 'name':

code:

Unknown custom element: <btn> - did you register the component correctly? For recursive components, make sure to provide the "name" option.

How can I use Btn inside ModalConfirmation without creating this error? I've tried including a name property on each component like this, with no luck:

code:

@Component({
  name: "btn",
  components: {
    ModalConfirmation
  }
})
export default class Btn extends BtnProps {
  // ...
}

Side note: I am very new to Vue and I've almost definitely taken the wrong approach for this problem, so I'm happy to have some general advice on how to support modals and confirmation etc if anyone has any advice. If I can somehow trigger the modal to show without having to include it in the Btn component that would be nice, bearing in mind that I want the modal content to be flexible so I can easily populate it with whatever content I need at the time.

# ? Mar 5, 2020 03:10

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

I can�t speak to Vue in particular, but modals are usually a global components that sit close to root (if for no other reason that it makes it easier for the modal to be modal), and then you harness some feature of the framework to either send messages to it or to spawn modals as needed. So your button wouldn�t have a modal in it, but would have a way to get to your global doohickey.

# ? Mar 5, 2020 04:08

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

I also can't speak to Vue but in react I'd jam that modal right next to the button in the component hierarchy, and then createPortal handles actually attaching it to the root node in the DOM. It may be the same for Vue (I should really learn some Vue at some point)

# ? Mar 5, 2020 06:09

men with puns: Feb 8, 2010; Young Orc

I don't think it's a problem to include the modal with your button component. If you don't, then some parent component would have to receive its click event and be able to launch a dialog for the confirmation, which sounds like it would be more complicated.

I think the problem is that you can't use a Btn component inside your Btn component's confirmation dialog, because that would make every "yes" or "no" button create another confirmation dialog when it's clicked. It sounds like you want the dialog to just have regular buttons, and the "yes" button could emit a confirm event when it's clicked that your Btn component could listen for.

# ? Mar 5, 2020 06:58

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

a hot gujju bhabhi posted:

I'm trying to make a button component in Vue that will optionally request confirmation before emitting its click event. I have a modal component that I use for displaying modal messages and I'm going to use that for this as well. The problem is if I do this, I need the confirmation modal to be a part of the button template so I can show/hide it from within the button component.

I'm simplifying because my component is a mess from fiddling with it, but essentially this is what I've got in my Btn component:
code:
<template>
  <fragment>
    <button @click="onClick">Some button</button>
    <modal-confirmation v-show="isConfirming" />
  </fragment>
</template>

<script lang="ts">
import Vue from "vue";
import ModalConfirmation from "modal-confirmation.vue";

const BtnProps = Vue.extend({
  props: {
    confirm: Boolean
  }
});

@Component({
  components: {
    ModalConfirmation
  }
})
export default class Btn extends BtnProps {
  isConfirming: boolean = false;

  onClick(e) {
    if (this.confirm) {
      this.isConfirming = true;
    } else {
      this.$emit("click", e);
    }
  }
}
</script>
The problem I'm facing is that the modal confirmation itself also contains two Btn components for the "yes" or "no" buttons. So now I'm getting an error in the console saying for recursive components I need to set a 'name':
code:
Unknown custom element: <btn> - did you register the component correctly? For recursive components, make sure to provide the "name" option.
How can I use Btn inside ModalConfirmation without creating this error? I've tried including a name property on each component like this, with no luck:
code:
@Component({
  name: "btn",
  components: {
    ModalConfirmation
  }
})
export default class Btn extends BtnProps {
  // ...
}
Side note: I am very new to Vue and I've almost definitely taken the wrong approach for this problem, so I'm happy to have some general advice on how to support modals and confirmation etc if anyone has any advice. If I can somehow trigger the modal to show without having to include it in the Btn component that would be nice, bearing in mind that I want the modal content to be flexible so I can easily populate it with whatever content I need at the time.

Hey. Vue is my daily driver at work and has been for about a year now.

Dupersaurus has the right idea here. Typically a modal is global, then accessed inside of a component via this.$modal or something similar. Basically setup your modal component to have like show/hide methods, and Vue.use() it in your app so that it's global, then you can access it anywhere. A confirm component would basically be the same thing, and take a title as props or whatever. Then have the button click events return a promise of true/false and go from there. Then in whatever component you need, you can go

pre:

this.$confirm('do you want to continue?').then((yesno) => {
  if(yesno) {
    // user has confirmed.
  }
});

Also, I can't tell from your code above, are you using vue-class-component and/or vue-property-decorator? I see @Component, but I don't see it imported, and then you're doing Props the "old" way. Mixing styles gets super confusing in the long run.

As for your button problem, I would say your approach is odd if you want a generic button component. Reason being, buttons that need a confirm are very likely a subset of buttons that do not, and there's no need for the ones that do not to ever know about a modal component. I would make a generic button, then extend it into a separate confirm-button class which handles a confirm popup, then emits the result to whatever parent it resides in. That will eliminate your circular reference problem Vue is complaining about since btn and confirm-btn are two different things, and btn knows nothing about a modal.

Another thing to think about is: do you need a generic button component? It's easy enough to go: <button @click="handleClick">Derp</button> and add a class or two for styling. No need to over-complicate something that wasn't complicated in the first place. A confirm-button is a good use case for a component, but to me, a generic button is not.

Just my $0.02.

Feel free to PM me if you have other questions.

# ? Mar 5, 2020 13:39

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

Thanks all for the advice, much appreciated. Very much a backend dev by trade so this is all kind of voodoo to me.

HaB posted:

Hey. Vue is my daily driver at work and has been for about a year now.

Dupersaurus has the right idea here. Typically a modal is global, then accessed inside of a component via this.$modal or something similar. Basically setup your modal component to have like show/hide methods, and Vue.use() it in your app so that it's global, then you can access it anywhere. A confirm component would basically be the same thing, and take a title as props or whatever. Then have the button click events return a promise of true/false and go from there. Then in whatever component you need, you can go
pre:
this.$confirm('do you want to continue?').then((yesno) => {
  if(yesno) {
    // user has confirmed.
  }
});
Also, I can't tell from your code above, are you using vue-class-component and/or vue-property-decorator? I see @Component, but I don't see it imported, and then you're doing Props the "old" way. Mixing styles gets super confusing in the long run.

As for your button problem, I would say your approach is odd if you want a generic button component. Reason being, buttons that need a confirm are very likely a subset of buttons that do not, and there's no need for the ones that do not to ever know about a modal component. I would make a generic button, then extend it into a separate confirm-button class which handles a confirm popup, then emits the result to whatever parent it resides in. That will eliminate your circular reference problem Vue is complaining about since btn and confirm-btn are two different things, and btn knows nothing about a modal.

Another thing to think about is: do you need a generic button component? It's easy enough to go: <button @click="handleClick">Derp</button> and add a class or two for styling. No need to over-complicate something that wasn't complicated in the first place. A confirm-button is a good use case for a component, but to me, a generic button is not.

Just my $0.02.

Feel free to PM me if you have other questions.

Thanks for taking so much time to help out. I like what you've described with the confirm modal, and I'll take a look at the Vue.use method to try to understand how that works although at a quick glance that might be too much for me at the moment.

I also like the idea of extending the Btn component but to be honest I have no idea how to even approach this, I mean literally from a syntax point of view - how do I do that. One of the problems I'm finding (and you've touched on it when you mentioned my mixing and matching of props/vue-class-component) is that every time I look up something each author has their own approach. Between options API, class components, composition API, property decorators, etc, etc... It's really hard to try to figure out what is the best practice way to be doing this, and how the different approaches map across - so if I read an article about doing something and they use the composition API, how do I map that same technique to the options API, for example.

I think in general I just could benefit from a good Vue video series or something that is consistent and up to date, if anyone has any suggestions... Or alternatively an example of a Vue project on GitHub or something that is generally well designed so I can see for myself.

Regarding the button component, I just want the buttons to look consistent everywhere without having to style them in a global stylesheet - I like to try to keep the styles with the components as much as possible.

Edit: as an example wrt the extending Btn thing... I had a go at this and ended up with something similar to this:

code:

<template>
  <button :class="classes" :type="type" @click="onClick">
    <slot></slot>
  </button>
</template>

<script lang="ts">
import Vue from "vue";
import { Prop, Component } from "vue-property-decorator";

@Component
export default class Btn extends Vue {
  @Prop({ default: "" })
  label!: string;

  @Prop({ default: "button" })
  type!: string;

  @Prop({ default: "" })
  color!: string;

  get classes() {
    const classList: string[] = [];

    classList.push("btn");

    switch (this.color) {
      case "danger":
        classList.push("btn--danger");
        break;
    }

    return classList;
  }

  onClick(e) {
    this.$emit("click", e);
  }
}
</script>

Then I made a BtnConfirm component that looked like this:

code:

<template>
  <fragment>
    <btn :class="classes" :type="type" @click="onClick">
      <slot></slot>
    </btn>
    <confirmation-modal v-if="isConfirming" @yesClicked="onClickYes" @noClicked="onClickNo" />
  </fragment>
</template>

<script lang="ts">
import Vue from "vue";
import Component from "vue-class-component";
import { Btn, ConfirmationModal } from "@/components/common";
import { Fragment } from "vue-fragment";

@Component({
  components: {
    Btn,
    ConfirmationModal,
    Fragment
  }
})
export default class BtnConfirm extends Btn {
  isConfirming: boolean = false;

  onClick(e) {
    this.isConfirming = true;
  }

  onClickYes(e) {
    this.isConfirming = false;
    this.$emit("click", e);
  }

  onClickNo(e) {
    this.isConfirming = false;
  }
}
</script>

But now I'm getting this error, which makes no sense to me because the modal is imported correctly and I've not mistyped its name or anything, so I can only assume I've somehow hosed up the extending of Btn:

code:

Unknown custom element: <confirmation-modal> - did you register the component correctly? For recursive components, make sure to provide the "name" option.

putin is a cunt fucked around with this message at 22:55 on Mar 5, 2020

# ? Mar 5, 2020 22:20

Doom Mathematic: Sep 2, 2008

IAmKale posted:

One thing that immediately comes to mind for me is Airbnb's JavaScript styleguide: https://github.com/airbnb/javascript

I personally feel that their styleguide (implemented in my projects via the corresponding ESLint config) improved the general quality and readability of my code in projects I wrote afterwards; their explanations for all of the rules are well-thought out from their collective experiences with JS and so I found it easier to code to their standards since they seem as close to "practical best practices" as we have right now.

At the very least you'll probably pick up a JS gotcha or two that you can keep in mind to avoid in the future even if you don't follow these standards to the T.

How much of AirBnB's style guide needs to be read and thought about, and how much of it do you just immediately understand once you start using their ESLint config?

# ? Mar 5, 2020 22:39

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

Doom Mathematic posted:

How much of AirBnB's style guide needs to be read and thought about, and how much of it do you just immediately understand once you start using their ESLint config?

23% / 77%

# ? Mar 5, 2020 23:24

Dr. Krieger: Apr 9, 2010

a hot gujju bhabhi posted:

Thanks all for the advice, much appreciated. Very much a backend dev by trade so this is all kind of voodoo to me.

Thanks for taking so much time to help out. I like what you've described with the confirm modal, and I'll take a look at the Vue.use method to try to understand how that works although at a quick glance that might be too much for me at the moment.

I also like the idea of extending the Btn component but to be honest I have no idea how to even approach this, I mean literally from a syntax point of view - how do I do that. One of the problems I'm finding (and you've touched on it when you mentioned my mixing and matching of props/vue-class-component) is that every time I look up something each author has their own approach. Between options API, class components, composition API, property decorators, etc, etc... It's really hard to try to figure out what is the best practice way to be doing this, and how the different approaches map across - so if I read an article about doing something and they use the composition API, how do I map that same technique to the options API, for example.

I think in general I just could benefit from a good Vue video series or something that is consistent and up to date, if anyone has any suggestions... Or alternatively an example of a Vue project on GitHub or something that is generally well designed so I can see for myself.

Vue has tons of great patterns, docs and examples but very few in typescript at the moment, unless you're building a pretty complex web application where you would really benefit strong typing I'd probably just use regular JS and core Vue while you learn the framework. Vue 3 is close to beta and is being completely rewritten in typescript so you won't have to use libraries like the vue-class-component and vue-property-decorator anymore, I currently work on a project using both of those to write Vue components with tyepscript and I feel the same pain you do with the lack of documentation for them and wouldn't want to use them until I had a really solid understanding of the base framework.

I haven't watched their videos but I took a Vuex workshop from the https://vueschool.io/ guys last year at Vueconf and it was great, looks like they have some free ones too if you want to get a feel for their style

Dr. Krieger fucked around with this message at 00:55 on Mar 6, 2020

# ? Mar 6, 2020 00:53

Spime Wrangler: Feb 23, 2003; Because we can.

Here's hoping Vue3 does a good job with typescript and it becomes widespread and well-supported, because the payoff is worth it.

I made the questionable decision of going all-in on typescript/class-component/property-decorator with our most recent vue app and after spending a shitload of time getting it working smoothly and figuring out some decent patterns I could never go back. We're building engineering tools that run on the client side though, so it seemed like a clear fit for our use case.

Speaking of adopting technologies too soon, we're looking at possibly compiling a C++ library to JS/WASM to crunch numbers client-side instead of running it on the server. Anyone have experience doing that? I've been poking at emscripten for a couple of days now and its output works well offline but I've had issues integrating it into the vue app.

# ? Mar 6, 2020 17:25

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

a hot gujju bhabhi posted:

Thanks all for the advice, much appreciated. Very much a backend dev by trade so this is all kind of voodoo to me.

Thanks for taking so much time to help out. I like what you've described with the confirm modal, and I'll take a look at the Vue.use method to try to understand how that works although at a quick glance that might be too much for me at the moment.

I also like the idea of extending the Btn component but to be honest I have no idea how to even approach this, I mean literally from a syntax point of view - how do I do that. One of the problems I'm finding (and you've touched on it when you mentioned my mixing and matching of props/vue-class-component) is that every time I look up something each author has their own approach. Between options API, class components, composition API, property decorators, etc, etc... It's really hard to try to figure out what is the best practice way to be doing this, and how the different approaches map across - so if I read an article about doing something and they use the composition API, how do I map that same technique to the options API, for example.

I think in general I just could benefit from a good Vue video series or something that is consistent and up to date, if anyone has any suggestions... Or alternatively an example of a Vue project on GitHub or something that is generally well designed so I can see for myself.

Regarding the button component, I just want the buttons to look consistent everywhere without having to style them in a global stylesheet - I like to try to keep the styles with the components as much as possible.

Edit: as an example wrt the extending Btn thing... I had a go at this and ended up with something similar to this:
code:
<template>
  <button :class="classes" :type="type" @click="onClick">
    <slot></slot>
  </button>
</template>

<script lang="ts">
import Vue from "vue";
import { Prop, Component } from "vue-property-decorator";

@Component
export default class Btn extends Vue {
  @Prop({ default: "" })
  label!: string;

  @Prop({ default: "button" })
  type!: string;

  @Prop({ default: "" })
  color!: string;

  get classes() {
    const classList: string[] = [];

    classList.push("btn");

    switch (this.color) {
      case "danger":
        classList.push("btn--danger");
        break;
    }

    return classList;
  }

  onClick(e) {
    this.$emit("click", e);
  }
}
</script>
Then I made a BtnConfirm component that looked like this:
code:
<template>
  <fragment>
    <btn :class="classes" :type="type" @click="onClick">
      <slot></slot>
    </btn>
    <confirmation-modal v-if="isConfirming" @yesClicked="onClickYes" @noClicked="onClickNo" />
  </fragment>
</template>

<script lang="ts">
import Vue from "vue";
import Component from "vue-class-component";
import { Btn, ConfirmationModal } from "@/components/common";
import { Fragment } from "vue-fragment";

@Component({
  components: {
    Btn,
    ConfirmationModal,
    Fragment
  }
})
export default class BtnConfirm extends Btn {
  isConfirming: boolean = false;

  onClick(e) {
    this.isConfirming = true;
  }

  onClickYes(e) {
    this.isConfirming = false;
    this.$emit("click", e);
  }

  onClickNo(e) {
    this.isConfirming = false;
  }
}
</script>
But now I'm getting this error, which makes no sense to me because the modal is imported correctly and I've not mistyped its name or anything, so I can only assume I've somehow hosed up the extending of Btn:
code:
Unknown custom element: <confirmation-modal> - did you register the component correctly? For recursive components, make sure to provide the "name" option.

That all looks correct. Only thing I can see: I assume @/components/common has an index file? At any rate, try doing an explicit import of the ConfirmationModal.vue file directly. I have definitely had weird issues where index files just....don't work?

Only other thing I can think of is that the ModalConfirmation isn't correctly exporting itself.

# ? Mar 6, 2020 19:10

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

HaB posted:

That all looks correct. Only thing I can see: I assume @/components/common has an index file? At any rate, try doing an explicit import of the ConfirmationModal.vue file directly. I have definitely had weird issues where index files just....don't work?

Only other thing I can think of is that the ModalConfirmation isn't correctly exporting itself.

Sorry for the slow reply, I actually worked this out through pure dumb trial and error but you were right - the import using the Index file was loving it up. You're a legend, wish I'd seen your reply sooner!

The latter, ModalConfirmation not exporting itself correctly, is what I played around with for hours to no avail because it was right all along haha. Ugh.

putin is a cunt fucked around with this message at 22:14 on Mar 12, 2020

# ? Mar 12, 2020 22:10

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

Spime Wrangler posted:

Here's hoping Vue3 does a good job with typescript and it becomes widespread and well-supported, because the payoff is worth it.

I made the questionable decision of going all-in on typescript/class-component/property-decorator with our most recent vue app and after spending a shitload of time getting it working smoothly and figuring out some decent patterns I could never go back. We're building engineering tools that run on the client side though, so it seemed like a clear fit for our use case.

Speaking of adopting technologies too soon, we're looking at possibly compiling a C++ library to JS/WASM to crunch numbers client-side instead of running it on the server. Anyone have experience doing that? I've been poking at emscripten for a couple of days now and its output works well offline but I've had issues integrating it into the vue app.

Yeah I think the decorator stuff is a pretty good fit for larger projects or at least projects where you can afford to spend the time and energy devising a really good and robust pattern that you can follow. In my project, in hindsight, I really should have just gone with the simplest approach since a) I'm not a Vue developer, or even any kind of front end developer and b) This is an MVP, getting it complete is more important at the moment than getting it perfect.

Oh and yeah I'm hoping the same for Vue3, TypeScript is good normally, it's a shame it's so clunky in Vue at this moment.

putin is a cunt fucked around with this message at 22:15 on Mar 12, 2020

# ? Mar 12, 2020 22:13

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

On the topic of Vue 3 - I'm having a crack at migrating from Vue 2 to the alpha of Vue 3.

I'm getting stuck right from the start because in my main.ts where I use: import { createApp } from "vue"; when I try to build I receive a message saying the module "vue" cannot be found:

code:

This dependency was not found:

* vue in ./src/main.ts

Is there something else that might be incorrect in my setup that would stop a definitely installed component from importing correctly? (I did try deleting my node_modules and package-lock.json in order to reinstall it all fresh, but no luck.

Edit: it doesn't help that the Vue CLI updated from v2 to v3 in the past so every search for migrating from Vue 2 to Vue 3 just brings up old stuff related to the CLI... ugh.

putin is a cunt fucked around with this message at 03:46 on Mar 16, 2020

# ? Mar 16, 2020 03:08

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 09:08

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

a hot gujju bhabhi posted:

On the topic of Vue 3 - I'm having a crack at migrating from Vue 2 to the alpha of Vue 3.

I'm getting stuck right from the start because in my main.ts where I use: import { createApp } from "vue"; when I try to build I receive a message saying the module "vue" cannot be found:
code:
This dependency was not found:

* vue in ./src/main.ts
Is there something else that might be incorrect in my setup that would stop a definitely installed component from importing correctly? (I did try deleting my node_modules and package-lock.json in order to reinstall it all fresh, but no luck.

Edit: it doesn't help that the Vue CLI updated from v2 to v3 in the past so every search for migrating from Vue 2 to Vue 3 just brings up old stuff related to the CLI... ugh.

I hate to be that guy but - isn't the correct module name "Vue" not "vue"?

# ? Mar 16, 2020 12:47

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

«‹›235 »