Nouvelle interface d'upload d'image

En faisant un peu de recherche je suis tombé sur cette lib pour l’upload d’image. Il y a également une doc.

Si quelqu’un est intéresser pour implémenter cette fonctionnalité, il peut du coup ce basé sur cette lib.

Je ne le fais pas moi-même car ces temps si je fais une overdose de web et Python me répugnent.

C’est vite fait de le faire sans cette lib donc -1. Après je suis totalement pour une tel fonctionnalité mais peut-être sans lib donc +1, soit 0.

Ensuite, quand il était question du d’n’d, il était question de l’intégrer au futur éditeur :

C’est vite fait de le faire sans lib donc -1.

je comprends pas cet argument.

L’éditeur de sandhose est beau mais il n’est pas prêt, je pense qu’il vaut mieux créer le drag and drop avec ce qu’on a aujourd’hui plutôt que d’attendre encore. C’est une fonctionnalité qui a été demandée par la communauté avec une assez forte participation.

Je n’ai pas trop eu le temps de regarder la lib d’heziode. mais j’y jetterai un oeil quand j’aurai le temps.

Le drag’n’drop est très vite intégré en JavaScript sans librairy c’est une question de quelques lignes. Je ne comprends pas l’ajout d’une tel librairie pour une tel fonctionnalité.

Par exemple : https://github.com/A-312/chat-client/blob/89859561a6926937bfb9e2a67bb26d1f0dc00d51/javascript/chat.js#L75

pour le coup tu utilises quand même jquery pour intégrer le tout.

J’ai pu regarder la bibliothèque montrée par @heziode, elle semble correspondre à notre besoin :

• pas de jquery
• insertion d’image + retour avec un code markdown
• et le code est assez petit

JavaScript a choisi comme philosophie, dans son écosystème, d’avoir des petites bibliothèques qu’on monte comme dse légo à l’envie. Je ne vois pas l’intérêt de recoder moi même la couche dialogue et gestion d’erreur si une lib le fait pour moi et que j’ai juste à la configurer.

Tout le code du zds utilise jquery, je ne comprends pas la volonté de faire sans.

EDIT : Je parlais de jQuery parce qu’elle est utilisée sur le site je ne me rappelais pas que l’éditeur était sans. Ce qui ne change pas grand chose.

C’est @sandhose qui préférerait, demande-le lui.

Mais je réagissais au fait que tu disais "sans bibliothèque". Bah si tu utilises jquery. Personnellement, j’ai déjà implémenté la chose avec un plugin jquery donc y’a pas de soucis. Mais comme le code front a surtout été maintenu et amélioré par @sandhose je pense normal qu’il ait son mot à dire sur ce qu’il est préférable de faire.

J’utilise tellement jQuery que je ne l’excluais pas dans ma phrase. jQuery c’est le JS 2.0 du front end. EDIT 2 : Après c’est facile de faire sans, il faut juste prévoir quelques lignes en plus.

Edit 3 : JS 2.0 dans le sens qu’avec jQuery c’est très facile de modifier le DOM.

Le problème des bibliothèques en front qui ajoute un bloc de fonctionnalité :

• Ça limite la personnalisation possible sinon il faut modifier le code de la bibliothèque ;
• L’intégration est suffisamment simple pour ne pas se restreindre à l’utiliser.

EDIT : Bref, c’est qu’une question d’avis personnelle et je n’ai pas envie de tenir une deuxième fois ce débat. Surtout que je suis le seul à tenir ce point de vue.

Je pense, @A-312 qu’ici c’est pas le débat "pour ou contre jquery". En fait mon message initial réagissait à "sans utiliser de lib".

Personnellement j’aime jquery, c’est confortable, c’est efficace et c’est fiable.

Mais zds est un projet collectif, il faut que l’équipe puisse utiliser les outils qui vont bien tout en permettant à des nouveaux d’arriver. Et jquery renforce encore plus l’aspect "spaggethi" qu’on trouve dans certain code front. Du coup, même si, personnellement, j’aimerais utiliser le plugin jquery kivabien je comprends que @sandhose demande à ce qu’on évite le plus possible d’utiliser jquery.

Ensuite, il y a la gestion des cas aux limites et c’est là que prendre une lib externe peut être un bon choix. Je regarderai si c’est bon avec la lib proposée par héziode.

Enfin, JQuery c’est quand même pas mal vieillissant. Si ton image de "js 2.0" est vrai, alors on devrait dire qu’ajourd’hui on en est au js 6.0. JQuery c’est une bonne lib de prototypage sur le front (utilisée par bootstrap) et qui a de l’avenir, mais ce n’est plus la révoltion que c’était lors de sa création.

Tu n’es pas développeur frontend, je me trompe ?

EDIT 2 : Après c’est facile de faire sans, il faut juste prévoir quelques lignes en plus.

Prenons la lib proposée par Heziode :

❯ wc -c jquery.inline-attachment.min.js inline-attachment.min.js
    4493 jquery.inline-attachment.min.js
    4513 inline-attachment.min.js
    9006 total

/tmp/InlineAttachment/dist master
❯ echo $((4513-4493))
20

Sur une lib de ~4.4Ko avec et sans jQuery, la version utilisant jQuery utilise 20 caractères de moins que celle avec. (<= Cette phrase fait 119 caractères.)

C’est vous qui commencez à me faire parler de jQuery et je n’avais pas l’intention de débattre la dessus.

@cepus Tu as pris le temps de regarder le contenu des fichiers ? Sinon tu aurais compris que ta comparaison n’a aucun sens. Comme je n’aime pas faire de devinettes, je t’aide un peu ça passe ici et à l’occasion fait une différence entre deux fichiers.

Ce que je voulais dire surtout : Ma seule crainte dans une fonction toute faite comme ça, c’est que ça ne soit pas adapté à notre besoin et qu’elle soit difficilement personnalisable. Alors que la version native est très accessible.

Pourquoi avoir masqué tes messages? Je ne comprends pas le principe.

Pour ce qui est de ta crainte, on verra, c’est vrai que c’est possible, mais tant que personne n’a fait de POC, on ne peut pas vraiment dire.

En tous cas pour rebondir sur le sujet et parce que c’est ce que je me suis mangé au boulot : quand tu as une belle stack babel + webpack et que tu as un projet qui se pointe en supposant un plugin jQuery, c’est une grosse merde à intégrer à ta stack.

Je me permet juste d’intervenir parce que dans l’éditeur que j’avais commencé, j’avais implémenté l’insertion d’image au drag and drop ; la partie récupérer l’image droppée était pas très compliqué, et j’avais tout ce qu’il fallait pour manipuler du texte dans l’éditeur pour que ça soit pas ~trop compliqué d’ajouter le code de l’image en place. Ça pourrait être intéressant de reprendre cet éditeur un de ces quatre.

Mais effectivement, j’aurais tendance à éviter d’ajouter des trucs qui dépendent de jQuery pour ce genre de trucs.