Reprise du message précédent :
Bha la question a pas trop de sens car théoriquement n'est inclus au build que l'utile ... donc rien dans le cas d'un HelloWorld :
css : 0ko car tous les imports scss seraient commentés car besoin d'aucun composant UI
js: le poids d'un hello world angular. Pareil, tant que j'importe rien, le bundle ne contiendra pas angular material. Si j'importe, le treeshaking fera le ménage.
 
C'est différent d'un site plus silmpliste où tu load monframework.full.js et monframework.full.css mais je suis pas sûr de t'apprendre grand chose

Bonjour,
 
dans Google Search Console, j'ai une alerte sur la "Mobile Usability" de mon site. J'ai deux erreurs : "Clickable elements too close together" et "Content wider than screen" concernant une page du site.
 
Je n'arrive pas à savoir quels éléments provoquent ces erreurs. Je clique sur les messages d'erreur puis sur l'URL en faute, et je fais "Test live version" pour en savoir plus. Et là Google Search Console analyse et me dit que ma page est bien mobile friendly !  
Autre chose : si je clique sur "Validate fix", il me renvoie un mail quelques jours après pour me dire qu'effectivement, l'erreur semble être réglée. Mais dès qu'il revient crawler mon site un peu plus tard, l'alerte revient…
 
Quelqu'un d'autre a-t-il eu la même chose ? Si oui, qu'avez-vous fait ?

drap

J'ai passe plus d'une heure sur ce probleme, et je trouve pas la solution.
 
https://stackoverflow.com/questions [...] -javasript
 
Il s'agit d'émuler un click sur le div d'un site. Jusque là rien de bizarre, sauf qu'on arrive pas à le faire... Notre investigation est en commentaire de la question.

je pense que tu les a énervé en postant pas de code

sinon femme et enfant dans l'avion pour la Suisse, je suis LIBERÉEEEEE, DELIVRÉEEEEEEEE, la maison est à moi toute la semaine.

Oublie pas de poster "I figured it out" sans plus de précision.

 
A la base c'est même pas ma question, j'aimerais juste comprendre.

Oui, oui Ahmad, on y croit  

et en dispatchant un event ?

Marchera pas, le framework du truc garde une référence interne des évenements et assigne une valeur à la propriété __satellite__ des events. Faut forger l'event pour qu'il soit processé, sinon il dégage.
 

V.handleEvent = function(e) {
        if (!V.$data(e, "eventProcessed" )) {
            var t = e.type.toLowerCase()
              , n = e.target || e.srcElement
              , a = 0
              , i = V.rules
              , r = (V.tools,
            V.evtHandlers[e.type]);
            if (V.isVMLPoisoned(n))
                V.notify("detected " + t + " on poisoned VML element, skipping.", 1);
            else {
                r && V.each(r, function(t) {
                    t(e)
                }),
                n && n.nodeName ? V.notify("detected " + t + " on " + n.nodeName, 1) : V.notify("detected " + t, 1);
                for (var o = n; o; o = o.parentNode) {
                    var s = !1;
                    if (V.each(i, function(t) {
                        V.ruleMatches(t, e, o, a) && (V.notify('Rule "' + t.name + '" fired.', 1),
                        V.fireRule(t, o, e),
                        a++,
                        t.bubbleStop && (s = !0))
                    }),
                    s)
                        break
                }
                V.$data(e, "eventProcessed", !0)
            }
        }
    }

J'ai trouvé un moyen de contourner le truc étant donné que cette partie du code est en Vue.js.
 

document.querySelector(".se-pagination-button.se-pagination-button--next" ).__vue__._events.tap[0]()

Tellement degueux

Si Vue ne stockait pas son bordel sur l'élément ça aurait été difficile de contourner le truc  

document.querySelector(".se-pagination-button.se-pagination-button--next" ).__vue__._events.tap[0]()

 
 
Thx! <3

document.querySelector(".se-pagination-button.se-pagination-button--next" ).__vue__._events.tap[0]()

Ca a l'air bien stable comme API en +

Mais pas d'autres moyens, et la plupart des frameworks stockent une référence sur les éléments dom qu'ils controlent

document.querySelector(".se-pagination-button.se-pagination-button--next" ).__vue__._events.tap[0]()

Je ne connais pas Vue.js. Je regarderais comment la librairie de test simule le click. Parfois, il y a une combinaison d'évènements, c'est pourquoi un simple appel ne suffit pas.

Je doute que les tests fassent appel à des APIs privées.

pendant les vacances, j'ai pris un peu de temps pour me remettre à jour sur react  
 
Autant, je ne suis pas super fan des hook (ça me semble du sucre syntaxique qui complexifie la lecture du code), autant provider/consumer est une merveille, et j'attends avec impatience suspense pour la partie data fetching

On me demande de savoir si je peux rendre ce site responsive : http://webdocumentaire.filmm.org/#!/

Je zieute vite fait, Angular + Bootstrap.
Je connais BS, mais je connais pas du tout Angular. Du coup, si j'édite les styles avec les règles RWD, Angular va pas couiner ? Ou vaut mieux que je refuse la proposition ?
Budget du client : 2200€

Thx

Bof tu serais vite limité et ce serait du travail crade.
Ce serait un site plus simple/standard, oui ca se fait, mais là ya pas mal d'animations, le menu/navigation serait à refaire, etc..
Je vote : non.

nique sa mère y'a du son en autoplay, jamais de la vie j'accepte un tel client  

Bon de toutes façons j'ai refusé la proposition, j'aime pas faire le pompier sur ce genre de sites moches.
 
Thx les kheys

drap

Par contre si ça intéresse quelqu’un je peux filer le projet ! (Budget 2200€)
J’ai déjà les maquettes responsives

oh ptin, tout est géré au hover...  

 
Je l'aurais bien pris mais je suis full en ce moment
 
--
 
Sinon, je repasse sous windows pour mon laptop et ça fait bien rager les devs autour de moi

Salut blabla@web
 
Vous connaissez des stratégies de sortie d'ember.js ? Il y en a parmi  vous qui ont réussi à migrer une (grosse) appli d'ember à autre chose ? Si oui comment ? Combien de temps cela a pris ? Vous avez un retour d'expérience à ce sujet ?

On est en Ember aussi.
Par curiosité, qu'est-ce qui vous amène à migrer ? Je vois pas mal de raisons potentielles, mais ça m'intéresse de connaître les vôtres et notamment ce qui a été déclencheur.

On a pas encore pris la décision de migrer, mais ça mûri doucement.
Notre propre legacy est en grande partie responsable de nos problèmes, mais il reste des points noirs typiquement ember :
 
- on n'arrive pas à up de 2.12 à 2.16 - sans doute à cause de notre legacy, mais ça reste un très gros problème
- la doc devient de plus en plus imbitable et la communauté se réduit de plus en plus. Quand on recherche des trucs sur ember, on tombe sur des vieux trucs, rarement sur du récent, sauf peut-être quand il s'agit de migrer justement
- on passe 2x plus de temps sur les tests que sur le code - aussi bien sur la maintenance des tests existants que sur l'écriture de nouveaux tests
- les changements de paradigmes continuels - pour un framework qui prône les conventions, et qui en change tout le temps, c'est quand même contradictoire
- pour certaines choses, on ne sait jamais comment il faut faire, on tâtonne. Par exemple, les actions : send ? sendAction ? Autrement ?
 
Voilà ce qui me passe par la tête.
 
Du coup je serais curieux par ton feedback aussi

de ce que j'en vois, vous aurez probablement les mêmes problèmes avec d'autres framework pour les points 3/4/5, voir pire

J'adore react, mais niveau stabitilité des conventions, c'est la folie (arrivée des hook, des provider, de suspense) . Par contre ils sont super niveau retro compatibilité

 
Tu as des exemples ?
 
Il me semble que cela s’est beaucoup stabilisé depuis la version 2.0.  
 
Je peux vous filer un coup de main pour voir si ça vous débloque

Les points forts
+ Fullstack (CLI + Core + Data) : chez nous, c'est un énorme avantage, celui que j'ai poussé à l'époque pour l'adoption d'Ember chez nous et pour lequel je ne regrette toujours pas. Il n'y a pas de dev front permanent chez nous, ni même d'expert JS (langage, mais surtout écosystème). Avoir un FW qui gère tous les aspects front est un gain de temps sur le dev et la formation.
+ La stabilité, d'autant plus impressionnante quand on regarde le reste du monde JS. Le mode de release, les LTS, l'ajout de fonctionnalités, les modes de déprécations (et l'addon de workflow associé)... Sur le long terme, c'est vraiment quelque chose qui donne confiance dans le FW. Il n'y a qu'à lire les posts de release pour se rendre compte du sérieux apporté au suivi.
+ Doc homogène (pas parfaite on est d'accord)
+ La productivité est vraiment bonne AMHA
+ La facilité de migration : pour ce point je viens en opposition à ton constat, mais on a fait le choix de partir full composants lors de la migration 1.X vers 2.X, sans regrets. On a peu de dépendances, on utilise les services et les composants à foison. Les migrations sont parfois un peu touchy (routeur notamment, mais aussi actions comme tu le signales), mais dans l'ensemble ça se fait bien.

Les trucs nuls :
- pas une grosse communauté (le point que tu évoquais sur la fraicheur des réponses sur SO/Discuss/whatever)
- pas un gros pool de développeur, donc grosse difficulté à staffer l'équipe (cet unique point pourrait nous faire migrer)
- le paradigme de communication encouragé entre front et API est la JSON-API. Je pense qu'un contrat est nécessaire, mais JSON-API n'est pas très répandu côté prise en charge back, et surtout très consommateur en termes de requêtes. GraphQL me fait vraiment de l’œil.
- support TypeScript (uniquement Glimmer ?)

Les trucs pas testés mais qui ont l'air cool sur le papier :
+ Glimmer pour les besoins plus légers
+ SSR
+ Octane pour cette année

Typescript n’est pas limité a Glimmer.js ( https://github.com/typed-ember/ember-cli-typescript )
Les développeurs faisant du React s’adapte généralement rapidement à Ember.
 
Il faut savoir que LinkedIn est devenu à Ember ce que Facebook est à React ou Google à Angular.
 
Il faut s’attendre à beaucoup de progrès puisque ce qui était développé en pure open source avant va être pousser désormais par des personnes travaillant à temps plein sur le framework.

https://2018.stateofjs.com/front-en [...] /overview/

React reste quand meme bien devant, dans l'ensemble les gens n'ont pas spécialement l'air de s'intéresser a Ember.
La seule fois ou j'ai entendu parler de Ember c'était dans un obscur meetup il y a 2 ans perso  

A moins d'être dans une très grosse boite, ou d'avoir un besoin vraiment spécifique j'ai du mal a voir pourquoi choisir autre chose que React (ou Angular/Vue... ), ne serait-ce que pour la facilite de staffer comme dis plus haut.

Angular.
 
 

C'est ce que je trouve personnellement passionnant, et comme tu le dis niveau rétro-compatibilité c'est généralement parfait
 
Les hooks  

Disons qu'Ember avec sa courbe d'apprentissage et son objectif de developpement d'applications complexes n'est pas fait pour la masse de développeurs ou toutes les compagnies
Comparer React et Ember n'a quasiment que peu de sens vu qu'il n'y a pas le même scope.

Après, les devs JS, ca a l'air de s'emmerder et de toujours vouloir essayer un truc nouveau Pas mal de choses expliquent qu'Ember n'est pas plus populaire pour le "grand public" des developpeurs.

Mais Netflix ou LinkedIn ne l'utiliseraient pas si c'était mauvais.

Et en listant le rapport que tu as mis en lien
 

 
Moi je préfère gagner du POGNON que de me masturber tous les 12 mois sur un nouveau framework  

Je préfère faire un boulot que je trouve intéressant avec un poil moins de blé que bosser sur une techno que je trouve chiante et ramasser du blé
 
 
edit: quelle plaie de faire les accents sur le clavier qwerty  

 
   
 
Par contre tu as dit toi même ne pas connaitre donc tu ne sais pas ce que tu manques    

"Ember: think of it as doing Cobol in the banking industry"
 
comme accroche.