Uproszczenie kodu asynchronicznego.

Jak to można uprościć?

async function callAsyncAfterAll(cb) {
   return new Promise((resolve, reject) => {
      typeof cb !== 'function' && reject(new Error('This middleweare is not a function'));
      setTimeout(() => {
         resolve(cb());
      }, 0);
   });
};

const proxy = () => callAsyncAfterAll(checkSpecialCharacters);

const checkSpecialCharacters = () => {
   const regex = new RegExp(`(${regexVal})+`, 'g');
   editor2.value = editor.value.replace(regex, (val) => {
      return `<div>${val.trim()}</div>`;
   });
}

editor.addEventListener('keyup', proxy);

mam taki kod jak wyżej, chcę,, aby przy każdym naciśnięciu przycisku wykonywała się funkcjia asynchronicznie, i po wykonaniu wsyzstkich, takich funkcji będzie więcej....jak można się pozbyć tego proxy?

Podaj jakis opisowy, konkretny przykład (bez kodu) bo nie do końca łapie jaki efekt chcesz uzyskać.

No rozchodzi się o to że, jeśli nacisnę przycisk, to wyzwalają* się funkcje, do edycji tekstu(Taki edytor). No i żeby wykonywały się wszystkie asynchronicznie, bo użytkownik dalej może pisać. Nie może go zaciąć. No i ten settimeout aby wykonać te funkcje po wszystkim, czyli jakby jakieś były funkcje synchroniczne, etc.

*fajne słowo, musiałem użyć.

mateusz1231r4 napisał(a):

No rozchodzi się o to że, jeśli nacisnę przycisk, to wyzwalają* się funkcje, do edycji tekstu(Taki edytor). No i żeby wykonywały się wszystkie asynchronicznie, bo użytkownik dalej może pisać. Nie może go zaciąć. No i ten settimeout aby wykonać te funkcje po wszystkim, czyli jakby jakieś były funkcje synchroniczne, etc.

*fajne słowo, musiałem użyć.

Chyba za bardzo kombinujesz. Silnik javascript sam dba o to (za pomocą event loop), by wykonywane funkcje jak najmniej blokowały użytkownika.
Nie wiem ile tych funkcji chcesz tam odpalać, ale nie sądzę by wykonywały się dłużej niż kilka, kilkanaście milisekund.

To że dodasz tam słowo async, czy promise nie znaczy, że kod będzie się wykonywał w inny sposób niż normalnie. Jakoś ludzie pisali asynchroniczny kod długo zanim pojawiły się promise i async. Javascript jest asynchroniczny z natury. Takie funkcje służą tylko do tego, by w łatwy sposób określić kiedy wykonanie danego kodu się skończy, ale nie zmieniają jego działania.

Kombinowanie z event loopem za pomocą setTimeout(() => { ... }, 0); jest praktycznie nigdy przydatne. Jeśli są rzeczywiście jakieś problemy z wydajnością, to najczęściej używa się window.requestAnimationFrame() albo nowsze window.requestIdleCallback() , ale to tylko w rzadkich sytuacjach naprawdę ciężkich skryptów. Nie ma sobie co tym głowy zawracać.

Tak więc pisz kod normalnie:

const checkSpecialCharacters = () => {
   const regex = new RegExp(`(${regexVal})+`, 'g');
   editor2.value = editor.value.replace(regex, (val) => {
      return `<div>${val.trim()}</div>`;
   });
}

editor.addEventListener('keyup', checkSpecialCharacters);

m31 napisał(a):

Chyba za bardzo kombinujesz. Silnik javascript sam dba o to (za pomocą event loop), by wykonywane funkcje jak najmniej blokowały użytkownika.

Nie do końca.

Nie wiem ile tych funkcji chcesz tam odpalać, ale nie sądzę by wykonywały się dłużej niż kilka, kilkanaście milisekund.

U mnie już 30ms sprawia, że edytor nie działa płynnie. Jak ktoś robi średniozaawansowany edytor z przetwarzanie syntaksu, analizą błedów itp to nie problem przekroczyć ten czas.

To że dodasz tam słowo async, czy promise nie znaczy, że kod będzie się wykonywał w inny sposób niż normalnie. Jakoś ludzie pisali asynchroniczny kod długo zanim pojawiły się promise i async. Javascript jest asynchroniczny z natury. Takie funkcje służą tylko do tego, by w łatwy sposób określić kiedy wykonanie danego kodu się skończy, ale nie zmieniają jego działania.

Tutaj to jakieś herezje piszesz, JS wykonuje kod synchrony synchronicznie, nie robi tu żadnej dodatkowej magii by nie blokować głównego wątku.

Kombinowanie z event loopem za pomocą setTimeout(() => { ... }, 0); jest praktycznie nigdy przydatne.

Rzadko, ale nie nigdy, nawet ostatnio był na forum przypadek gdzie było to przydatne: https://4programmers.net/Forum/JavaScript/330059-innerhtml_jak_przechwycic_zakonczenie_renderowania_elementu

Jeśli są rzeczywiście jakieś problemy z wydajnością, to najczęściej używa się window.requestAnimationFrame() albo nowsze window.requestIdleCallback()

Tu pełna zgoda.

@mateusz1231r4

Nie wydaje mi się byś potrzebował tam zwracać promisa (bo i tak w callbacku eventa nic z wartością wynikową nie zrobisz, wszystko i tak robisz w samym callbacku).

Użyj może czegoś takiego:

/**
 * @param {Function} fn - function that should be run on idle
 * @param {Object} options - options object for requestIdleCallback (not required)
 */
const idle = (fn, options) => (event) => {
  if (typeof fn !== 'function') {
    throw new Error('This callback is not a function')
  }
  
  window.requestIdleCallback((deadline) => fn(event, deadline), options)
}

Jak tego użyć w kodzie:

editor.addEventListener('keyup', idle(checkSpecialCharacters));

Demo: https://codepen.io/caderek/pen/GRKOPZB?editors=0011

PS
Tak w ogóle, to potrzebujesz tam raczej jakiegoś debounce, bo odpalanie obliczeń co znak nie ma za bardzo sensu jak ktoś jest w trakcie pisania.