# Appel développeur les prochaines semaines?

**URL:** <https://community.gladysassistant.com/t/appel-developpeur-les-prochaines-semaines/7358>\
**Category:** Développement\
**Created:** [Juin 10, 2022, 12:15 UTC](https://community.gladysassistant.com/t/appel-developpeur-les-prochaines-semaines/7358 "2022-06-10T12:15:57Z")\
**Posts on this page:** 1\
**Showing post:** 42

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [Juillet 11, 2022, 2:52 UTC](https://community.gladysassistant.com/t/appel-developpeur-les-prochaines-semaines/7358/42 "2022-07-11T14:52:44Z")

</div>

@AlexTrovato @VonOx Pour info j’ai fais un test de rendre la fonction .emit de notre EventEmitter global asynchrone !

Je me suis inspiré du code de cette lib qui est assez connue (mais bon, trop complète pour nous, on a pas besoin de tout ça):

> **[GitHub - sindresorhus/emittery: Simple and modern async event emitter](https://github.com/sindresorhus/emittery)**
>
> Simple and modern async event emitter. Contribute to sindresorhus/emittery development by creating an account on GitHub.

ça donne ça niveau code, c’est vraiment tout simple:

> <https://github.com/GladysAssistant/Gladys/pull/1569/files>
>
> \### Pull Request check-list
> 
> To ensure your Pull Request can be accepted as fa…st as possible, make sure to review and check all of these items:
> 
> \- \[\] If your changes affects code, did your write the tests?
> \- \[\] Are tests passing? (\`npm test\` on both front/server)
> \- \[\] Is the linter passing? (\`npm run eslint\` on both front/server)
> \- \[\] Did you run prettier? (\`npm run prettier\` on both front/server)
> \- \[\] If you are adding a new features/services, did you run integration comparator? (\`npm run compare-translations\` on front)
> \- \[\] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to \[the community\](https://community.gladysassistant.com/) for testing before merging.
> \- \[\] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code)
> \- \[\] If you are adding a new features/services which needs explanation, did you modify the user documentation? See \[the GitHub repo\](https://github.com/GladysAssistant/v4-website) and the \[website\](https://gladysassistant.com).
> \- \[\] Did you add fake requests data for the demo mode (\`front/src/config/demo.js\`) so that the demo website is working without a backend? (if needed) See \[https://demo.gladysassistant.com\](https://demo.gladysassistant.com).
> 
> NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open.
> 
> \### Description of change
> 
> Please provide a description of the change here. It's always best with screenshots, so don't hesitate to add some!

En gros, à chaque fois qu’on emit un event, l’event ne sera publié de façon synchrone «&nbsp;qu’après&nbsp;», on laisse la main à Node.js de faire ce qu’il veut entre l’appel de la fonction et l’emit synchrone.

Dans le cas d’appareils qui engendrerait des centaines d’emit, (qui eux même généreraient des centaines d’emit, car on vérifie plein de choses: les scènes, websockets vers le front, etc…), chaque event n’est pas consommé de façon synchrone, mais de façon asynchrone quand Node.js peut.

ça devrait résoudre les soucis avec les appareils comme le Linxee TIC

Vous en pensez quoi ?

Edit: @VonOx vu que c’est un changement de quelques lignes, tu pourrais remplacer le fichier dans ta prod et voir l’effet que ça a, voir si ça résout bien le soucis ?

---

_[View the full topic](https://community.gladysassistant.com/t/appel-developpeur-les-prochaines-semaines/7358)._