Repository navigation
Make it possible for worker to query parent #51
Description
Currently we only have
host ---query---> worker ---response---> host
Allow the worker to query to host. This is useful for stuff like notifications and even simple log debugging.
Activity
Allow all compiler options
basarat commentedon Feb 5, 2015
Just a word of caution : since we are using
nodeon windows, and notio.js(which has built inPromise) likeatom, Once I've promisified thehost->clientcode, we will need to use somePromiselibrary for worker.[-]Make it possible to worker to query parent[/-][+]Make it possible for worker to query parent[/+]disable notification till #51
basarat commentedon Feb 23, 2015
One use case we badly need it for is #110 So moving this to a higher priority.
Use case 1
When a child comes up it should query the parent about all the files it has open and their contents. This will make sure that the child (by default working on the file system) is never out of date from the server.
Note: This can also be solved by the parent by just sending the data to the child.
Use case 2
The child is very aggressive about keeping its tsconfig up to date. This is great for new ts files, removed ts files, tsconfig changed. Currently child can only reload it all from the file system and cannot notify the parent that it would like in memory changes also. This will allow the child to query the parent for this information and we can be less aggressive about pushing the data to the child e.g. on active tab change.
Use case 3
Add message type for notifications. Useful for debugging
Use case 4
Add messages for files that are built. This will potentially require mid execution call-out from
project.abstracted away parent.ts into a class
abstracted child into a class in the workerlib
abstracted as much of the functionality as I can between parent and c…
basarat commentedon Feb 26, 2015
As soon as one thing is async. Everything is async. If we want true (query->response) within a function executing in the child we already need to make all our functions promise based.
basarat commentedon Feb 26, 2015
Its not strictly required, as our use cases not really need the child to stop midway before responding to the parent query. But being completely async at some point is a good idea to have at some point. So now that I've done the grunt work, I will commit it. However it does make it a bit hard for a newbie to understand the project. I apologize to that person. Nevertheless promises are something that every decent JS developer will eventually need to learn. I will do a separate iteration of making debugging easier + documentation.
basarat commentedon Feb 26, 2015
Plus I suspect it will help us if the language service ever becomes async microsoft/TypeScript#1857
make the project service (fake) async
consistent naming for parent and child. Also `childQuery` is now `sen…
basarat commentedon Feb 26, 2015
One issue to solve now is of cyclic references. child ---needs as a responder---> projecService ----needs to query ----> child. Doable, just needs more refactoring and thought.
basarat commentedon Feb 26, 2015
Note: 👍 on promisifying: Having the same signature
Query -> Promise<Response>for the IPC / local versions of the functions means they can be swapped in and out of process quite easily