Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 246 sur 309 PremièrePremière ... 146196236238239240241242243244245246247248249250251252253254256296 ... DernièreDernière
Affichage des résultats 7 351 à 7 380 sur 9267
  1. #7351
    Citation Envoyé par Fastela Voir le message
    J'ai commencé à coder il y a 15 ans avec un livre « PHP 4.0 » que m'avais offert un oncle
    J'espère que c'était le bouquin qui a lancé les meilleurs d'entre les meilleurs



    J'ai passé tellement de temps a bouquiner ce livre un peu partout.


  2. #7352
    Citation Envoyé par Fastela Voir le message
    Ben typiquement je comprends pas trop comment déclarer un objet « générique » quand une fonction est censée accepter un peu nimp.
    Alors la forme la plus simple va être de ce type :
    Code:
    function test<T>(arg1: T): T {
        return arg1
    }
    Ça c'est une fonction qui prend un argument unique en entrée de type T et qui retourne une valeur de ce même type T.
    Sauf que vu qu'on a rien spécifié sur le type T, ben on va pas aller très loin.

    Un exemple un peu plus parlant peut ressembler à ça :
    Code:
    type Toto = {
        tata: number
    }
    
    function test<T extends Toto>(arg1: T): number {
        return arg1.tata * 2
    }
    
    test() // erreur (pas d'argument alors que la fonction en attend 1)
    test('a') // erreur (mauvais type d'argument)
    test({ 
        tata: 1
    }) // ok
    test({ 
        tata: 1,
        titi: 2
    }) // ok
    Notre fonction test accepte en argument tous les objets qui contiennent au minimum les propriétés de Toto, fait un calcul dessus et retourne un nombre.

    Citation Envoyé par Fastela Voir le message
    J'essaie d'éviter au max any
    Et c'est très bien, any n'est à réserver qu'en dernier recours.
    Si il y a un endroit dont tu ne connais vraiment pas le type, utilise plutôt unknown.
    Le compilateur te forcera dans ce cas à faire des vérification sur la variable/argument pour l'utiliser.

    Citation Envoyé par Fastela Voir le message
    mais on dirait que Record<string, number> me paraît être une astuce de forain (et je comprends pas ce qu'est Record à la base).
    Un Record est juste un object classique dont on définie les types possible pour ses clés et ses valeurs.

    Exemple :
    Code:
    type Test = Record<string, number>
    
    const a: Test = {} // ok
    const b: Test = {
        a: 'a'
    } // erreur
    const c: Test = {
        a: 1
    } // ok
    Exemple 2 :
    Code:
    type Test = Record<string, number> // C'est objet dont les clés sont des string, et les valeurs sont des number
    
    const a: Test = {} // ok
    const b: Test = {
        a: 'a'
    } // erreur (la valeur associée à la clé a est de mauvais type)
    const c: Test = {
        a: 1
    } // ok
    Autre exemple :
    Code:
    enum TestEnum {
        A = 'a',
        B = 'b'
    }
    
    type Test = Record<TestEnum, number> // C'est objet dont les clés sont toutes les valeurs de TestEnum, et les valeurs sont des number
    
    const a: Test = {
        a: 'a'
    } // erreur (la valeur associée à la clé a est de mauvais type)
    const b: Test = {
        a: 1
    } // erreur (l'objet doit contenir toutes les valeurs en TestEnum en clé)
    const c: Test = {
        a: 1,
        b: 2
    } // ok
    const d: Test = {
        [TestEnum.A]: 1,
        [TestEnum.B]: 2
    } // ok
    const e: Test = {
        [TestEnum.A]: 1,
        [TestEnum.B]: 2,
        c: 3
    } // erreur (c ne fait pas partie de TestEnum)
    Après pour tout ce qui est généricité/types avancés, mieux vaut se baser sur des exemples concrets pour comprendre et qu'on puisse répondre au mieux à tes interrogations.

    Citation Envoyé par Fastela Voir le message
    Je sais pas trop ce que veulent dire les chevrons aussi
    Les chevrons servent à déclarer/passer des types génériques.

    Citation Envoyé par Fastela Voir le message
    et j'ai pas trop capté quel était la meilleure pratique pour déclarer ses interfaces. Pour l'instant je les fourre toutes dans un fichier .ts et je les exporte pour ensuite faire un import { Person } from '@/interfaces' dans mon composant Vue par exemple.
    En général on essaie de déclarer les types/interface proche de l'endroit où ils sont utilisés.
    Si c'est utilisé dans un composant unique, déclare les à côté de ce composant.
    Si c'est utilisé dans plusieurs composant, déclare les dans le dossier parent commun.

    edit : quelques autres exemples de typage que j'ai posté sur l'autre topic de prog :

    Citation Envoyé par Orhin Voir le message
    Ah oui effectivement ça peut être très utile dans ces cas.

    Y'a un truc similaire en Typescript avec les types mappés où tu peux définir les propriétés acceptées/obligatoires pour un objet.
    Si je reprend ton exemple du pixel tu peux faire :
    Code:
    // Pas obligé d'assigner des valeurs explicites à l'enum mais plus pratique pour déclarer les objets et accéder à leurs propriétés
    enum Colors {
      Red = 'red',
      Green = 'green',
      Blue = 'blue'
    }
    
    // Pas de range en TS malheureusement pour l'instant, donc déclarer les valeurs de 0 à 255 est plutôt moche
    type ColorValue = 0 | 1 | 2 | 4
    
    // Record<K, V> est un type générique de base qui accepte les types de propriétés (K) et des valeurs (V) de l'objet
    type Pixel = Record<Colors, ColorValue>
    
    const a: Pixel = {
      [Colors.Red]: 0,
      [Colors.Green]: 0,
      [Colors.Blue]: 0,
    } // OK
    
    const b: Pixel = {
      red: 0,
      green: 0,
      blue: 0,
    } // OK
    
    const c: Pixel = {
      red: 5,
      green: 0,
      blue: 0,
    } // Error
    
    const d: Pixel = {
      red: 0,
      blue: 0,
    } // Error
    
    const e: Pixel = {
      red: '0',
      green: '0',
      blue: '0',
    } // Error
    
    
    const f: Partial<Pixel> = {
      red: 0,
    } // OK
    
    const test1 = 5
    const test2: number = 4
    const test3 = 4
    const test4: ColorValue = 4
    
    a.red = test1 // Error
    a.red = test2 // Error
    a.red = test3 // OK
    a.red = test4 // OK
    a[Colors.red] = test4 // OK
    a['red'] = test4 // OK
    Bien sur ça reste du check à la compilation pas au runtime (JS interprété oblige), mais c'est très utile.
    Citation Envoyé par Orhin Voir le message
    D'ailleurs pour l'exemple des tableaux avec un nombre min/max d'éléments tu peux le faire en partie en TS avec des tuples :

    Code:
    type Pixel = {
      red: number,
      green: number,
      blue: number
    }
    
    type Pixels = [Pixel, Pixel, Pixel?, Pixel?] // Min 2 éléments, 4 max
    
    const a: Pixel = {
      red: 0,
      green: 0,
      blue: 0
    }
    
    const b1: Pixels = [a] // Error
    const b2: Pixels = [a, a, a, a] // Ok
    const b3: Pixels = [a, a, a, a, a] // Error
    
    const b4: Pixels = [a, a, a, a]
    
    b2[0].blue // OK
    b2[3].blue // Error
    b2[5] // Error
    b2[0] = b2[3] // Error
    b2[3] = b2[1] // OK
    b2[0] = b2[3] // OK car détection de l'assignation au dessus
    
    type Pixels2 = [Pixel, Pixel,  ...Pixel[]] // Min 2 éléments, pas de max
    
    const c1: Pixels2 = [a] // Error
    const c2: Pixels2 = [a, a] // Ok
    
    c2[0].blue // OK
    c2[3].blue // Error si compil avec noUncheckedIndexedAccess, OK sinon (ou alors il faut déclarer le type comme ça [Pixel, Pixel, ...(Pixel | undefined)[]])
    c2[3] // OK
    c2[0] = c2[3] // Error
    c2[3] = c2[1] // OK
    c2[0] = c2[3] // OK car détection de l'assignation au dessus
    Par contre ça reste limité vu que :
    - y'a pas de check sur les méthodes de modifications des arrays (pop, push, splice, etc)
    - la déclaration de type est clairement pas faisable avec des min/max importants


    Ah clairement mais si tu peux avoir les deux c'est encore mieux.
    Dernière modification par Orhin ; 17/06/2021 à 16h33.
    C'est la faute à Arteis

  3. #7353
    Ah super merci beaucoup Orhin ça éclaire un peu ma lanterne ! Juste une question c'est quoi le <T> ici ?

    Code:
    function test<T>(arg1: T): T {
        return arg1
    }

  4. #7354
    Citation Envoyé par Fastela Voir le message
    Ah super merci beaucoup Orhin ça éclaire un peu ma lanterne ! Juste une question c'est quoi le <T> ici ?

    Code:
    function test<T>(arg1: T): T {
        return arg1
    }
    Un type générique T.
    En gros la signature de la fonction là dit juste que tu auras le même type pour arg1 et pour le retour de la fonction.
    Sauf qu'on ne sait rien de ce type.

    Ce qui est différent de :
    Code:
    function test(arg1: any): any {
        return arg1
    }
    Car dans ce cas rien ne garantit que le type de arg1 et du retour de la fonction sont le même.

    Là c'est un exemple assez peu parlant mais voici un truc un peu plus terre à terre :

    Code:
    type AbstractPayload<T> = {
        timpestamp: number
        data: T
    }
    
    type NumberPayload = AbstractPayload<number>
    type StringPayload = AbstractPayload<string>
    
    const a: NumberPayload = {
        timpestamp: 0,
        data: 0
    } // ok
    
    const b: NumberPayload = {
        timpestamp: 0,
        data: '1'
    } // error
    
    console.log(a.data * 2) // Ok
    console.log(b.data.toFixed()) // Ok
    
    const c: StringPayload = {
        timpestamp: 0,
        data: '1'
    } // Ok
    
    console.log(c.data.toUpperCase()) // Ok
    console.log(c.data.toFixed()) // error
    
    type ComplexPayload = AbstractPayload<string> & {
        truc: number
    }
    
    const d: ComplexPayload = {
        timpestamp: 0,
        data: '1',
    } // error (manque la propriété 'truc')
    
    
    const e: ComplexPayload = {
        timpestamp: 0,
        data: '1',
        truc: 0
    } // Ok
    
    function extractPayloadData<T>(payload: AbstractPayload<T>): T {
        return payload.data
    }
    
    const aData = extractPayloadData(a)
    console.log(aData.toFixed()) // Ok
    console.log(aData.toUpperCase()) // error car le compilateur infère que aData est de type number
    extractPayloadData(d).toUpperCase() // ok
    La fonction extractPayloadData prend en argument n'importe quel payload de type AbstractPayload et retourne la valeur de la propriété data.
    Le truc intéressant avec la généricité ici c'est que du coup le compilateur va connaitre le type de retour en fonction de ce que tu lui files en entrées et va donc pouvoir détecter les mauvaises utilisations que tu en fais.
    C'est la faute à Arteis

  5. #7355
    Il y a du lead dev ici ?

    Je suis intégrateur, j'ai 7 ans d'xp, j'étais sur un gros projet depuis 6 mois en solo. Le client a tanné ma boîte pour qu'on mette plus de monde sur le projet du coup on a pris plein de prestataires et on m'a dit que j'allais devoir chapeauter les 3 fronts qui allaient se ramener. J'ai jamais fait ça de ma vie et j'étais absolument pas préparé à ça. C'est assez bizarre de passer la moitié de sa journée à faire autre chose que du code mais bon on prend le pli, au final ça me plait pas mal.

    Le problème c'est que sur les 3 fronts qui sont arrivés une d'entre eux fait n'importe quoi. Je parle pas du fait qu'elle mette beaucoup de temps pour faire quelque chose qui me semble assez simple. Ca encore ça peut s'expliquer par des expériences différentes du métier. C'est plutôt le fait qu'elle fait n'imp dans ses commits, elle crée des régressions. Elle a déjà commité une fois ses fichiers de conf Drupal, depuis on m'a demandé de vérifier toutes ses pull request et régulièrement je tombe sur des trucs comme ça



    Je sais pas du tout comment réagir vis à vis de ça, je dois décliner littéralement 3 merge sur 4 tellement elle vérifie pas ce qu'elle envoie. Je suis même pas son supérieur vu que mon rôle a été défini de manière yolo-esque et que c'est une presta mais ça me tue de devoir lui dire toutes les 3h qu'elle fait du caca.

    Bref ceci était un post d'exteriorisation de ma frustration

  6. #7356
    Citation Envoyé par zatura Voir le message
    Il y a du lead dev ici ?

    Je suis intégrateur, j'ai 7 ans d'xp, j'étais sur un gros projet depuis 6 mois en solo. Le client a tanné ma boîte pour qu'on mette plus de monde sur le projet du coup on a pris plein de prestataires et on m'a dit que j'allais devoir chapeauter les 3 fronts qui allaient se ramener. J'ai jamais fait ça de ma vie et j'étais absolument pas préparé à ça. C'est assez bizarre de passer la moitié de sa journée à faire autre chose que du code mais bon on prend le pli, au final ça me plait pas mal.

    Le problème c'est que sur les 3 fronts qui sont arrivés une d'entre eux fait n'importe quoi. Je parle pas du fait qu'elle mette beaucoup de temps pour faire quelque chose qui me semble assez simple. Ca encore ça peut s'expliquer par des expériences différentes du métier. C'est plutôt le fait qu'elle fait n'imp dans ses commits, elle crée des régressions. Elle a déjà commité une fois ses fichiers de conf Drupal, depuis on m'a demandé de vérifier toutes ses pull request et régulièrement je tombe sur des trucs comme ça

    https://i.ibb.co/sP0rqRR/Capture-d-c...-21-104218.jpg

    Je sais pas du tout comment réagir vis à vis de ça, je dois décliner littéralement 3 merge sur 4 tellement elle vérifie pas ce qu'elle envoie. Je suis même pas son supérieur vu que mon rôle a été défini de manière yolo-esque et que c'est une presta mais ça me tue de devoir lui dire toutes les 3h qu'elle fait du caca.

    Bref ceci était un post d'exteriorisation de ma frustration
    C'est une presta, tu demandes à son responsable de la dégager et de te mettre une personne plus compétente à la place.

  7. #7357
    Dans son commit on voit qu'elle a push sans relire ses modifications.
    L'assignation de la variable 'image' c'est pour ses tests.
    Bon maintenant vous avez un placehold.it à la place, RIP les srcset, mais vous avez au moins du lazy loading natif

    Mon avis :

    - Faire des merge request pour TOUTES les modifications
    - Faire une review de code systématique en insistant sur le fait que les gens doivent être leurs premiers reviewer (là en relisant elle aurait vu son oubli)

    - Faire le point avec le manager sur les compétences attendues (si c'est une junior est-ce qu'on se dit Ok on va l'encadrer ?).
    - Faire remonter ouvertement les difficultés (donc PAS dans le dos de la personne)


  8. #7358
    Citation Envoyé par tenshu Voir le message
    Dans son commit on voit qu'elle a push sans relire ses modifications.
    L'assignation de la variable '
    - Faire remonter ouvertement les difficultés (donc PAS dans le dos de la personne)
    Sur ce point, si y'a revue de code, je considère que les difficultés ont été remontés de manière ouvertes. zatura est pas son chef, ni son encadrant, d'après ce que j'ai lu. Ergo, c'est pas a lui de faire en sorte qu'elle s'améliore. Il fait les revues de code, en commentant bien et en expliquant le pourquoi des rejets et il remonte le souci en appuyant ses dire par les chiffres.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  9. #7359
    Ouai enfin on bosse entre humains hein, même si il s'avère que ses compétences sont trop faibles pour faire le job, pas besoin de se la jouer bureaucratie non plus.
    Suffit de lui dire poliment "écoute on a parlé de ceci cela, mais je vois que ça ne va toujours pas. Je vais devoir en parler à N+1, pas que veuille te planter ou quoi mais toi comme moi on peut voir que ça ne va pas là".


  10. #7360
    La question ne va pas trop se poser au final car le contrat entre sa boîte et la mienne s'arrête dans deux semaines. D'ici là je ronge mon freine et je bosse ma communication non-agressive.

    On m'a déjà demandé de faire un retour sur les trois fronts pour potentiellement prolonger le contrat pour un d'eux.
    Je pense que j'ai été assez soft dans la description que j'ai fait d'elle (pas comme ici quoi ).

    Le problème c'est surtout qu'on avait besoin de renfort en urgence sur un projet déjà avancé où c'était le gros rush et ma boîte avait expressément demandé des gens à l'aise et compétent sur du Drupal 9.

    Mais bon je vais pas vous apprendre que les commerciaux de SSII ça raconte parfois n'imp

  11. #7361
    Citation Envoyé par zatura Voir le message
    Drupal 9
    *crache par terre*


  12. #7362


    Citation Envoyé par tenshu Voir le message
    *crache par terre*
    Avoue t'es jaloux parce qu'on a pas fait appel à toi pour la mission

  13. #7363
    Citation Envoyé par Calys Voir le message
    Avoue t'es jaloux parce qu'on a pas fait appel à toi pour la mission
    Oula moi ça fait des années que je ne fais plus de Drupal (ou de cms en général), j'ai même démissionné d'un très bon job pour cette raison.
    Je suis très bien avec mes framework.


  14. #7364
    Je suis d'accord avec ce qu'il s'est dit plus haut. Comme partout, le principal c'est la communication.

    Tu as 7 ans d'expérience, ce n'est pas négligeable. Si elle a moins d'expérience que toi, tu dois lui en parler et lui montrer que tu ne peux pas accepter du code pareil. Ce n'est pas tant le fait qu'elle code mal (ça arrive et c'est réparable) mais comme tu le dis elle ne se relis pas. Peut-être n'a-t-elle pas l'habitude de travailler en équipe ? Peut-être n'a-t-elle jamais fait de code review ?

    J'avoue qu'en étant seul sur 99% de mes projets, ce n'est que depuis peu que je fais une vraie code review de mon propre code avant commit. C'est aussi parce que je m'impose des règles d'écriture grâce à Prettier et ESLint.

    Donc dans un premier temps, lui parler du problème, lui montrer ce que tu dois faire et en quoi cela te fait perdre du temps inutilement. Ensuite, si cela ne s'arrête pas, passer sur des choses un peu plus formelles : refuser les PR avec des commentaires brefs mais qui expliquent clairement pourquoi, et en parler avec le Scrum Master ou le N+1.

  15. #7365
    Citation Envoyé par tenshu Voir le message
    *crache par terre*
    C'est ça qui est bien quand on est intégrateur, osef total de la plateforme sur laquelle on bosse. Moi tant que j'ai du HTML ça me va

    Pour vous dire j'ai même fait du sharepoint

  16. #7366
    Vala, si ça se trouve elle a été vendue comme experte alors qu'elle est débutante. Pas marrant pour elle. Tu peux l'accompagner et l'aider à acquérir des bonnes pratiques.
    Si elle est sympa bien évidemment. Dans une précédente mission on avait qqun nul nul nul, et qui refusait tout commentaire ^^, bah l'équipe passait son temps à recoder ce qu'elle faisait (elle était interne, nous prestas), mais c'était une situation carrément extrême. Bien souvent, ça se résout ou s'améliore simplement en discutant, en bossant ensemble quoi. Peut être qu'elle n'ose pas demander de l'aide ?
    Même si elle ne reste pas, l'aider qqes jours ça peut être un énorme gain pour elle. Y'a trop de débutants largués qui ne sont jamais aidés, du moins en presta.
    Dernière modification par gros_bidule ; 21/06/2021 à 19h26. Motif: ortho

  17. #7367
    Il pisse moins de markup qu'avant drupal ?
    Non par ce que quand je bossais dessus c'était un peu le festival des div et des span gratos.

    - - - Mise à jour - - -

    Citation Envoyé par gros_bidule Voir le message
    Y'a trop de débutants largués qui ne sont jamais aidés.
    Le problème c'est que quand ils sont placé par une boite qui les survend, bah ça peut pas faire l'affaire quoi.

    On a eu 2 personnes comme ça vendues comme senior ou medior (comme on dit ici) et en fait le compte n'y était pas.
    Le contrat a été rompu, puis en regardant leur linkedin j'ai vu qu'ils sont baladé de boites en boites de cette façon par des SSII (pardon des ESN).
    Que des expériences qui vont de 1 mois à un an grand max et qui tournent souvent plutôt autour de 3-6 mois.
    A la longue c'est un redflag en embauche, et arrivé en poste comme ils ne se débrouillent pas bien malgré x années "d'expérience" ça dégage.

    Du coup je ne peux que conseiller aux junior de faire attention à leur première expérience pro et si c'est dans un ESN de vraiment refuser de partir au casse pipe sur une mission pour laquelle on est de toute évidence pas qualifié.
    Dernière modification par tenshu ; 21/06/2021 à 19h57.


  18. #7368
    Yeah, mais ce n'est pas évident. Combien de jeunes presta indiquent bien qu'ils sont débutant lors de l'entretien chez le client final (avec le manager de l'ESN juste à côté), mais, par je ne sais quelle magie (allez, disons le post-entretien entre le client et le manager de l'ESN), ils se retrouvent soit à être vendu comme expert quand même, soit ils sont assignés à des technos auxquelles ils ont zéro xp. Là, autant on connaît la malhonnêteté des ESN, mais y'a aussi des baffes qui se perdent du côté du client final qui sait pourtant très bien que le jeune est un débutant.
    Ca et les jeunes ont souvent peur de s'imposer, et se contentent de subir ce management déplorable. Quand tu as 25 ans et c'est ta première mission dans un "grand groupe", tu es vite impressionné. Ce n'est pas pour rien qu'on dit parfois que les premiers jobs c'est de la prostitution : tu acceptes tout, pour un salaire de misère, et tu le fais avec le sourire s'il te plait. Et vas-y que tu avales... (des couleuvres hein ^^)

    On vit aussi une époque où le CDI est sacralisé. Tu ne peux plus refuser ou casser un CDI, tes proches ne comprendront pas, vu que tous les jours on parle de ces ingés et docteurs en trucbidule qui enchaînent les stages dans l'espoir de décrocher le saint CDI. Les gens (et les jeunes devs) ne savent pas que dans le secteur informatique on a l'immense chance de pouvoir choisir notre employeur, y'a bcp de boulot (même durant la pandémie). Donc ça peut expliquer que des jeunes acceptent tout et n'importe quoi.
    Dernière modification par gros_bidule ; 21/06/2021 à 19h47.

  19. #7369
    Citation Envoyé par gros_bidule Voir le message
    On vit aussi une époque où le CDI est sacralisé. Tu ne peux plus refuser ou casser un CDI, tes proches ne comprendront pas
    C'est la raison pour laquelle j'ai passé 9 ans de ma vie dans un boulot sous-payé et inintéressant. Pression parentale quand tu nous tiens.

  20. #7370
    Citation Envoyé par gros_bidule Voir le message
    Ce n'est pas pour rien qu'on dit parfois que les premiers jobs c'est de la prostitution : tu acceptes tout, pour un salaire de misère, et tu le fais avec le sourire s'il te plait. Et vas-y que tu avales... (des couleuvres hein ^^)
    A mais un job c'est de la prostitution même une fois devenu senior.
    C'est juste prostitution de luxe avec sélection du client et sortie dans les resto gastronomiques avec nuit au Ritz.

    C'est une des raisons qui me fait toujours hurler de rire quand j'ai un gugus qui me sort du champ lexical de la famille durant un entretien d'embauche d'ailleurs.

  21. #7371
    Citation Envoyé par tenshu Voir le message
    Il pisse moins de markup qu'avant drupal ?
    Non par ce que quand je bossais dessus c'était un peu le festival des div et des span gratos.
    Toujours autant mais personnellement je trouve ça plutôt pratique. C'est relativement rare les fois où j'ai besoin de toucher au markup généré par lui.

  22. #7372
    Je mettrai un bémol sur les propos précédents. J'ai rencontré beaucoup de seniors/experts/whatever totalement imbus d'eux-mêmes et persuadés d'être des cadors, alors qu'ils ont un niveau de merde. A un moment, faut connaître son niveau et reconnaître que l'on est mauvais (peu le font).

    La vidéo sur le code de merde est bien gentille, mais quand t'as affaire à un mec qui est buté et qui ne sait toujours pas coder après des années de pratique, tu fais quoi ? Tu continues à lui prendre la main jusqu'à la retraite ? Tu fais le boulot à sa place pour être tranquille ? On est bien payés dans nos jobs (ceux qui doutent, allez regarder le salaire médian en France), c'est normal d'être exigeant. Pour ceux qui n'y arrivent pas (ou plus), ce n'est pas sale de changer de boulot.

  23. #7373
    Le truc incompréhensible du jour (VueJS).


  24. #7374
    Citation Envoyé par Fastela Voir le message
    Le truc incompréhensible du jour (VueJS).

    https://i.ibb.co/7Qhw0JL/Screenshot-...2-14-26-30.jpg
    Alors je ne sais pas dans quel contexte tout ça est déclaré (je ne fais pas de VueJS), notamment l'objet watch.
    Mais il y a bien une différence entre tes 2 fonctions :
    - activeTask est une fonction classique et possède donc un this propre
    - editMode est une fonction flèche et ne possède pas de this propre

    Ça doit sans doute venir de là.
    C'est la faute à Arteis

  25. #7375
    C'est très certainement cela. Dans ce contexte, l'utilisation d'une fonction fléchée est clairement un anti-pattern.

    Citation Envoyé par MDN
    Une expression de fonction fléchée (arrow function en anglais) permet d’avoir une syntaxe plus courte que les expressions de fonction et ne possède pas ses propres valeurs pour this, arguments, super, ou new.target. Les fonctions fléchées sont souvent anonymes et ne sont pas destinées à être utilisées pour déclarer des méthodes.

  26. #7376
    Tain merci les canards, c'est exactement ça. Je sais pas pourquoi j'ai écrit ça comme ça. :D

  27. #7377
    Même en les limitant à un rôle de callback, je me suis déjà fait piéger une fois comme toi. L'autre grand moment de solitude, c'est quand pour la première fois j'ai voulu faire renvoyer un objet littéral par une fonction fléchée d'une seule ligne...

  28. #7378
    Citation Envoyé par GrandFather Voir le message
    Même en les limitant à un rôle de callback, je me suis déjà fait piéger une fois comme toi. L'autre grand moment de solitude, c'est quand pour la première fois j'ai voulu faire renvoyer un objet littéral par une fonction fléchée d'une seule ligne...
    Ben après pour le coup, utiliser le this d'une fonction pour accéder à des valeurs du contexte d'exécution, je trouve ça ultra moche.
    Soit c'est des méthodes de classes et this.$store a du sens (et dans ce cas une fonction flèche fonctionnera aussi), soit c'est des fonctions qui sont passées en callback quelque part et dans ce cas $store devrait être passé en argument.

    Concernant le retour d'un objet littéral par une fonction fléchée en une ligne, suffit juste de mettre des parenthèses :
    Code:
    const toto = () => ({ tata: 'titi' })
    C'est la faute à Arteis

  29. #7379
    Citation Envoyé par Orhin Voir le message
    Ben après pour le coup, utiliser le this d'une fonction pour accéder à des valeurs du contexte d'exécution, je trouve ça ultra moche.
    Soit c'est des méthodes de classes et this.$store a du sens (et dans ce cas une fonction flèche fonctionnera aussi), soit c'est des fonctions qui sont passées en callback quelque part et dans ce cas $store devrait être passé en argument.
    Sauf erreur de ma part, dans le code de Fastela cela ressemble plus à une injection d'une instance de store Vuex directement dans l'objet Vue ; l'instance est alors disponible dans chaque composant via this.

    Concernant le retour d'un objet littéral par une fonction fléchée en une ligne, suffit juste de mettre des parenthèses
    Oui, comme tu le dis, il suffit. Mais quand tu ne connais pas l'astuce, c'est pas le truc qui vient immédiatement et intuitivement...

  30. #7380
    Citation Envoyé par GrandFather Voir le message
    Sauf erreur de ma part, dans le code de Fastela cela ressemble plus à une injection d'une instance de store Vuex directement dans l'objet Vue ; l'instance est alors disponible dans chaque composant via this.
    Ah mais c'est bien ce que je comprend aussi, mais je trouve l'utilisation du this par Vue moche.
    C'est pas explicite (et assez peu intuitif pour les gens venant d'autres langages objets) contrairement au this d'une classe ou à un argument.

    Après c'est un ressenti qui vient surement du fait que je fasse surtout du React et de l'Angular.

    Citation Envoyé par GrandFather Voir le message
    Oui, comme tu le dis, il suffit. Mais quand tu ne connais pas l'astuce, c'est pas le truc qui vient immédiatement et intuitivement...
    Si ton typage est correct, le compilo Typescript va te dire tout de suite que t'as oublié le return si t'oublies les parenthèses.
    Et ton IDE devrait te demander aussi pourquoi t'es entrain d'écrire des labels inutiles (en tout cas Webstorm le fait).

    Je suis d'accord que c'est pas la syntaxe la plus intuitive, mais elle est plutôt logique : en JS tu peux mettre des parenthèses autour de n'importe quel expression dont tu veux utiliser le résultat.
    D'ailleurs si tu fais du React et que tu utilises Prettier, ce dernier va souvent ajouter des parenthèse dans le return des component pour pouvoir faire un saut de ligne entre le return le début du JSX.
    C'est la faute à Arteis

Page 246 sur 309 PremièrePremière ... 146196236238239240241242243244245246247248249250251252253254256296 ... DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •