You absolutely right 🙈 I just updated the code: github.com/atilafassina/solidjs-markdown/blob/main/src/routes/in/compose.tsx#L14-L20 Thanks a lot for this comment Philipp!! 🏆
It would make it more responsive when the md text becomes large. In the original version, because the parsing of the md was done on the main thread, keystroke processing would get more and more laggy. In the webworker version, because the parsing is being done in another thread, the main thread is free to process the keystrokes quickly while the worker does the parsing. In practice, you probably wouldn't fire off a parse request on every keystroke, because the parse requests would just end up getting queued while the worker was busy. You would track the busy state of the worker, and only fire off the next request when it became idle (at the expense of not seeing an update of the formatted text for every single keystroke in the md text).
In the example, aren't you adding an event listener every time the effect is run?
You absolutely right 🙈
I just updated the code: github.com/atilafassina/solidjs-markdown/blob/main/src/routes/in/compose.tsx#L14-L20
Thanks a lot for this comment Philipp!! 🏆
if not mistaken, we shouldn't put async with createEffect as suggested from their lint?
What is the font in your IDE?
I use VictorMono on the IDE
(rubjo.github.io/victor-mono/)
Hi Sir, can u try npm run build with this sample code? I see error when i build my project, which is very weird
I'll have a second look at this and re-record it with updated Solid deps. :)
Did it make the app faster?
It would make it more responsive when the md text becomes large. In the original version, because the parsing of the md was done on the main thread, keystroke processing would get more and more laggy. In the webworker version, because the parsing is being done in another thread, the main thread is free to process the keystrokes quickly while the worker does the parsing. In practice, you probably wouldn't fire off a parse request on every keystroke, because the parse requests would just end up getting queued while the worker was busy. You would track the busy state of the worker, and only fire off the next request when it became idle (at the expense of not seeing an update of the formatted text for every single keystroke in the md text).