Design & Développement web - Le topic des canards qui mangent des cookies

**Mayalabielle** · 31/07/2017, 21h43

https://blog.golang.org/pipelines, beauté et élégance de golang.

**Monsieur Odd** · 01/08/2017, 03h59

Envoyé par Orhin

Non mais surtout, quitte à prendre un truc overkill qui fait tout, autant partir sur un gros framework type Angular ou React.
Au moins ça permettra d'avoir un projet propre derrière.

Ca n'a rien à voir.

- - - Mise à jour - - -

Envoyé par Orhin

C'pour ça qu'on a inventé les observables.
En 5 lignes tu fais une fonction qui appelle de façon synchrone et séquentielle tes opérations asynchrones.
Ou alors qui les appelle toutes en parallèle mais attend qu'elles soient toutes finies pour passer à la suite.

Pour ton deuxième cas, un Promise.all() et basta.

**Orhin** · 01/08/2017, 11h13

Envoyé par Monsieur Odd

Ca n'a rien à voir.

Bah t'as quand même beaucoup d'opérations réalisées avec jQuery (manipulation du DOM, requête ajax) que tu ne fais plus manuellement avec des gros framework ce qui rends ton projet plus facilement maintenable.

Envoyé par Monsieur Odd

Pour ton deuxième cas, un Promise.all() et basta.

Effectivement.
Mais ça restait un exemple simple, y'a pas mal de cas où j'ai trouvé bien pratique de passer des promises aux observables (surtout en terme de lisibilité lorsque tu te mets à traiter des flux de données).

**Monsieur Odd** · 01/08/2017, 15h07

C'est sûr mais jQuery n'est un framework qu'envers lui même et si tu codes des modules. Pour le reste, c'est une librairie qui ne t'imposer rien et permets de faire n'importe quoi n'importe comment. Utilise systématiquement Angular ou React je suis pas sur que ce soit beaucoup plus pertinent.

**TarteAuxFleurs** · 04/08/2017, 17h59

Coin !
Je suis en train de faire un petit service web, et avec un formulaire j'ai besoin d'encapsuler le contenu d'un fichier dans une requête POST.
Le problème c'est que j'arrive pas à trouver un moyen de lire le fichier choisi par l'utilisateur puis de le foutre dans la requête.
Si en plus je peut carrément vérifier que c'est un fichier texte encodé en utf-8 alors c'est la fête !
Du coup si vous avez de la doc sous la main je suis preneur parce que je n'arrive pas a trouver mon bonheur sur les moteurs de recherche

**tenshu** · 04/08/2017, 18h04

Upload + Gestion de fichiers + encodage.

Tu codes avec quel langage déjà ?

**TarteAuxFleurs** · 04/08/2017, 18h14

Envoyé par tenshu

Upload + Gestion de fichiers + encodage.

Tu codes avec quel langage déjà ?

C'est du Rust avec le framework Rocket.
En l’occurrence c'est pour envoyer des fichiers CSV donc je veut juste vérifier côté front que le fichier est bien encodé en UTF-8 et le foutre dans le corps de la requête

Après côté serveur je fais ma tambouille, ça je gère

**Mayalabielle** · 04/08/2017, 18h20

Envoyé par gbip

C'est du Rust avec le framework Rocket.
En l’occurrence c'est pour envoyer des fichiers CSV donc je veut juste vérifier côté front que le fichier est bien encodé en UTF-8 et le foutre dans le corps de la requête

Après côté serveur je fais ma tambouille, ça je gère

Hannn cool, j'ai une semaine de vacance pour tester ce framework !

**TarteAuxFleurs** · 04/08/2017, 18h27

Envoyé par Mayalabielle

Hannn cool, j'ai une semaine de vacance pour tester ce framework !

Franchement fonce, la doc est vraiment au poil !

**tenshu** · 04/08/2017, 18h29

Envoyé par gbip

C'est du Rust avec le framework Rocketje veut juste vérifier côté front que le fichier est bien encodé en UTF-8 et le foutre dans le corps de la requête

Never trust user input.

Fais ça côté serveur, il doit bien y avoir un trick en rust pour faire ça.

**TarteAuxFleurs** · 04/08/2017, 18h32

Envoyé par tenshu

Never trust user input.

Fais ça côté serveur, il doit bien y avoir un trick en rust pour faire ça.

Bah l'idée c'est juste de mettre un warning sur la page voir d'empêcher l'envoi, côté serveur c'est blindé d'un point de vue entrée utilisateur !
Et pour la partie lecture/envoi ?

EDIT : J'ai trouvé, il faut pas oublier de spécifier l'attribut "name" dans la balise <input>, sinon c'est pas envoyé avec le formulaire.

**Orhin** · 04/08/2017, 20h17

Pour la lecture, je sais pas trop ce que t'as à dispo en Rust, mais tous les navigateurs modernes supportent l'API File : https://w3c.github.io/FileAPI/
A partir d'un input type file, tu peux récupérer un Blob ou un File.

**Monsieur Odd** · 05/08/2017, 12h37

Envoyé par gbip

EDIT : J'ai trouvé, il faut pas oublier de spécifier l'attribut "name" dans la balise <input>, sinon c'est pas envoyé avec le formulaire.

Cette boulette a la con.

le genre de coup qui arrivent fatigués et qui font perdre 3h.

**TarteAuxFleurs** · 05/08/2017, 12h52

Envoyé par Monsieur Odd

Cette boulette a la con.

le genre de coup qui arrivent fatigués et qui font perdre 3h.

Ouais mais l'avantage c'est que après tu la fais plus la boulette

(enfin j'espère ...)

**Monsieur Odd** · 05/08/2017, 14h28

Si si, ça fini toujours par arriver, ou oublier l'enctype.

**Dynames** · 23/08/2017, 15h06

Salut,

y'a t'il de bon connaisseurs en Angular?

Je débute avec et je n'ai pas vraiment un profil web à la base.

En ce qui concerne la partie structure je n'ai pas de soucis, l ou je coince un peu c'est sur la partie accès aux données.

Je suis en train de me faire une petite appli assez simples (genre blog avec différentes section : prez, articles, etc).

Je voudrais savoir si il y a moyen, de créer un service générique qui permette d'utiliser des fichiers json comme base de données, remplacé par une vraie base de données plus tard, et qui n'aurait aucun impact (ou faible) sur mon code.

Pour l'instant, mon service ressemble à ça (adapté à mon cas bien sur, mais les méthodes sont de la même forme), et y ressemblera sans doute avec une vraie bdd :

Code:

private headers = new Headers({'Content-Type': 'application/json'});
  private heroesUrl = 'api/heroes';  // URL to web api
 
  constructor(private http: Http) { }
 
  getHeroes(): Promise<Hero[]> {
    return this.http.get(this.heroesUrl)
               .toPromise()
               .then(response => response.json().data as Hero[])
               .catch(this.handleError);
  }
 
 
  getHero(id: number): Promise<Hero> {
    const url = `${this.heroesUrl}/${id}`;
    return this.http.get(url)
      .toPromise()
      .then(response => response.json().data as Hero)
      .catch(this.handleError);
  }

Quelle serait la meilleure manière de le faire?

N'étant pas du tout familier dans le domaine, je suis un peu perdu sur certaines doc qui ne donnent pas un exemple clair et complet (souvent découper pour démontrer un point en particulier, mais sans jamais lier les aspects qui m’intéressent).

Si je ne suis pas assez clair pour vous, n'hésitez pas à le dire.

**Orhin** · 23/08/2017, 15h41

Tes fichiers json sont stockés où ?
En bundle avec l'application ou accessibles via WS ?

Sinon, oui il faut bien utiliser un service qui abstrait l'accès aux données et l'injecter là où tu en auras besoin (components, autres services, resolvers, etc).

edit :
Quand tu parles de service "générique", tu parles du concept de généricité au sens programmation orientée objet (concept qui existe en typescript) et donc de faire une classe abstraite contenant les méthodes de base dont auront besoin les différents service qui en hériteront (un service qui renvois les objets de type Héro, un qui s'occupe de objet de type Machin, etc) ?

**Dynames** · 23/08/2017, 16h38

Envoyé par Orhin

Tes fichiers json sont stockés où ?
En bundle avec l'application ou accessibles via WS ?

Potentiellement les deux, si ça ne fait pas trop de différences. Sinon, j'imagine que le mieux serait via WS, que je n'ai pas encore bien regardé (exposé un json en WS).

Sinon, oui il faut bien utiliser un service qui abstrait l'accès aux données et l'injecter là où tu en auras besoin (components, autres services, resolvers, etc).

La, en l’occurrence, j'ai ce qu'il faut non? Hormis la source des données. J'ai bien ma classe Service, qui sera utilisé par les component (instancié dnas le constructeur).

Quand tu parles de service "générique", tu parles du concept de généricité au sens programmation orientée objet (concept qui existe en typescript) et donc de faire une classe abstraite contenant les méthodes de base dont auront besoin les différents service qui en hériteront (un service qui renvois les objets de type Héro, un qui s'occupe de objet de type Machin, etc) ?

Non je n'en suis pas encore là avec angular. Je voulais dire :

garder mes méthodes en ne changeant quasiment rien le jour ou je fais du json et le jour ou je fais de la bdd.

Mais après, peut être que je vais chercher trop compliquer, parce que je n'ai qu'une vision restreinte des possibilité angular et ts à l'heure actuelle.

Habituellement, je comprends bine plus rapidement les concepts, quand j'ai un gros projet concret et complet (complet ici serait avec html, module, component, service utilisant une bdd/ou des json). Dommage que la doc officielle angular ne comprenne pas un projet de ce type.

**Charmide** · 23/08/2017, 16h51

J'ai fait de l'angular 1.X pendant quelques années, c'est vieux maintenant mais à la fin j'avais "ma" vision d'une architecture efficace plutôt claire et j'ai jamais réussi à savoir si elle était "officiellement approuvée". Donc t'inquiètes pas c'est normal.

Ta structure me paraît pas mauvaise, la dernière fois que j'en ai fait (c'est vieux, donc) le service en angular ça n'était au final pas beaucoup plus qu'un singleton, angular s'assurant de l'unicité et du fait que tous les gens qui en ont besoin puisse accéder à cette instance unique. Ca suffit à s'assurer que ta logique est commune et partagée, et que tu auras qu'un endroit à changer si tu modifies la façon de stocker tes données.

**Orhin** · 23/08/2017, 17h09

Envoyé par Dynames

Potentiellement les deux, si ça ne fait pas trop de différences. Sinon, j'imagine que le mieux serait via WS, que je n'ai pas encore bien regardé (exposé un json en WS).

Si tu utilises Angular CLI (ce que je recommande très fortement), mets juste tes fichiers json dans le dossier assets (présent à la racine du projet).
Angular CLI s'occupera automatiquement de copier le contenu de ce répertoire dans le bundle.

Ensuite tu pourras y accéder via un GET avec l'url suivante : './assets/chemin_du_fichier'.
Le jour où tu veux le récupérer depuis un WS, tu n'auras juste qu'à changer cette URL.

Envoyé par Dynames

La, en l’occurrence, j'ai ce qu'il faut non? Hormis la source des données. J'ai bien ma classe Service, qui sera utilisé par les component (instancié dnas le constructeur).

Oui, l'exemple donné correspond à l'utilisation de base d'un service.

Par contre, attention à l’instanciation, elle n'est pas automatique !
Il faut pour ça déclarer le service dans les providers d'un module ou d'un component.
- Si tu le déclares dans les providers de ton component, chaque instance de ton component aura une instance de ce service différent (non recommandé dans un service servant à fetch des données).
- Si tu le déclares dans les providers dans module, alors tous les components de ce module (et des modules "fils") partageront la même instance du service.
=> Corollaire : si tu le déclares dans ton app.module.ts (= module root), alors le service sera un singleton.

Pour éviter de polluer le module root avec la déclaration des singletons, on créé généralement un module core, où tu déclares tous tes singletons dans providers, puis tu importes ce module core dans ton app.module.

Envoyé par Dynames

garder mes méthodes en ne changeant quasiment rien le jour ou je fais du json et le jour ou je fais de la bdd.

Comme dit plus haut, avec ton service actuel il te suffit de changer l'URL pour pointer vers des ressources différentes.
Après, un service ne gère généralement qu'un seul type de donnée (dans ton exemple, les Hero et liste d'Hero).
Du coup tu vas normalement créer un service par type d'objet et tu vas vite te retrouver avec du code dupliqué (par exemple ton handleError qui est identique pour tous tes services faisant des appels HTTP).
Dans ce cas, il va devenir intéressant de créer une classe abstraite générique contenant ces function redondantes, et d'en hériter pour chacun de tes services.

Si tu as d'autres questions n'hésite pas (d'ailleurs si tu peux partager ton projet sur github, on pourra facilement te faire des retours).

Envoyé par Charmide

J'ai fait de l'angular 1.X pendant quelques années, c'est vieux maintenant mais à la fin j'avais "ma" vision d'une architecture efficace plutôt claire et j'ai jamais réussi à savoir si elle était "officiellement approuvée". Donc t'inquiètes pas c'est normal.

Ta structure me paraît pas mauvaise, la dernière fois que j'en ai fait (c'est vieux, donc) le service en angular ça n'était au final pas beaucoup plus qu'un singleton, angular s'assurant de l'unicité et du fait que tous les gens qui en ont besoin puisse accéder à cette instance unique. Ca suffit à s'assurer que ta logique est commune et partagée, et que tu auras qu'un endroit à changer si tu modifies la façon de stocker tes données.

Attention, Angular 1.x (qu'on nomme AngularJS) et Angular 2+ (qu'on nomme juste Angular) sont assez différents sur pas mal de points.
Mais oui, c'est le framework qui s'assure d'instancier tes services au bon endroit via l'injection de dépendance.

**Mayalabielle** · 23/08/2017, 17h17

Ça fork chez node : voir https://github.com/ayojs/ayo https://twitter.com/alicegoldfuss/st...09726872068096 et https://news.ycombinator.com/item?id=15078995 pour plus de détail.

**TKN Jez** · 23/08/2017, 17h42

Wut?

**Charmide** · 23/08/2017, 17h43

Envoyé par Orhin

Attention, Angular 1.x (qu'on nomme AngularJS) et Angular 2+ (qu'on nomme juste Angular) sont assez différents sur pas mal de points.
Mais oui, c'est le framework qui s'assure d'instancier tes services au bon endroit via l'injection de dépendance.

Ouais je sais, d'où le fait que j'ai explicitement nommé 1.x et bien rajouté des couches sur le fait que c'était vieux.

**Dynames** · 24/08/2017, 08h27

Envoyé par Orhin

Si tu utilises Angular CLI (ce que je recommande très fortement), mets juste tes fichiers json dans le dossier assets (présent à la racine du projet).
Angular CLI s'occupera automatiquement de copier le contenu de ce répertoire dans le bundle.

Ensuite tu pourras y accéder via un GET avec l'url suivante : './assets/chemin_du_fichier'.
Le jour où tu veux le récupérer depuis un WS, tu n'auras juste qu'à changer cette URL.

Je comprends l'interêt de CLI, mais c'est simplement une simplification de la création des modules/componenent. Ca doit créer la structure de base dans le fichier ts j'imagine. Cela ne m'obligera pas à passer en lignes de commande pour créer mes modules, components, etc?

Etonné par contre de voir qu'ils n'ont pas prévu de router dans le CLI. Je pense qu'on en a vite besoin, et que ça aurait mérité de faire partie de la structure.

Sinon pour la artie json : ok, c'est ce genre de concept que je cherchais.

**PaulPoy** · 24/08/2017, 09h23

Envoyé par Mayalabielle

Ça fork chez node : voir https://github.com/ayojs/ayo https://twitter.com/alicegoldfuss/st...09726872068096 et https://news.ycombinator.com/item?id=15078995 pour plus de détail.

**Frypolar** · 24/08/2017, 10h23

Envoyé par Mayalabielle

Ça fork chez node : voir https://github.com/ayojs/ayo https://twitter.com/alicegoldfuss/st...09726872068096 et https://news.ycombinator.com/item?id=15078995 pour plus de détail.

Bon, en fait c’est juste de la tambouille interne, rien de technique.

**Nattefrost** · 24/08/2017, 10h26

Du bon shitstorm politique SJW vs Connards (pas trouvé de terme plus approprié).

**tenshu** · 24/08/2017, 10h28

Ca n'en est pas moins intéressant sur ycombinator j'ai vu quelqu'un dire que bon ça va c'est bon après tout si on appliquait le CoC de node à Linux ça fait très longtemps qu'on aurait dû virer Linus.

Moi je suis dans la team virer les gens racistes/sexistes/abusifs sur le champs, mais ça donne tout de même de quoi réfléchir.

- - - Mise à jour - - -

Envoyé par Nattefrost

Du bon shitstorm politique SJW vs Connards (pas trouvé de terme plus approprié).

Dommage ton point de vu on dirait les affreux centristes qui disent nazi += antifa

**Frypolar** · 24/08/2017, 10h34

Envoyé par Nattefrost

Du bon shitstorm politique SJW vs Connards (pas trouvé de terme plus approprié).

Ben Connards on sait pas trop justement. La partie publique de ce qui est reproché au mec c’est rien du tout (la critique d’un Code of Conduct hyper strict

). La partie privée a l’air un peu plus pertinente mais elle est privée...

**Orhin** · 24/08/2017, 12h06

Envoyé par Dynames

Je comprends l'interêt de CLI, mais c'est simplement une simplification de la création des modules/componenent. Ca doit créer la structure de base dans le fichier ts j'imagine. Cela ne m'obligera pas à passer en lignes de commande pour créer mes modules, components, etc?

Les générateurs de component/modules ne sont qu'une petite partie de l'intérêt du CLI (et oui tu peux tout à fait créer les fichiers à la main).

Ça te permet aussi de :
- lancer un serveur de test local en une seule commande => ng serve ;
- gérer les variables des différents environnements (dev, qa, prod, local) très simplement ;
- compiler le sass en css ;
- ne pas avoir à configurer webpack soit même pour tout ce qui est bundle/packaging/build de l'application ;
- etc

Bref, plein de trucs que tu pouvais faire à la main ou avec un task-runner (Gulp par exemple) sauf que t'as quasiment rien à configurer toi même.
Perso j'ai juste à lancer "ng build --prod --env=qa" et ça me créer un bundle prêt à déployer sur mon serveur de recette avec la bonne configuration.

Envoyé par Dynames

Etonné par contre de voir qu'ils n'ont pas prévu de router dans le CLI. Je pense qu'on en a vite besoin, et que ça aurait mérité de faire partie de la structure.

Je ne suis pas sur de comprendre.
Tu parles de l'absence de générateur de fichier de définition des routes ?
Si oui, y'en a pas vraiment besoin vu qu'elle sont définies au niveau des modules (généralement dans un fichier juste à côté).

Discussion: Design & Développement web - Le topic des canards qui mangent des cookies

Outils de la discussion

Règles de messages