Send message from web containers to the parent app
Opened this issue · 4 comments
Currently web containers are a one way thing. You cannot call a Jasonette action from inside web container, for example.
Making this two-way could be helpful.
WebView sending "Jason" to parent app, could probably trigger new view and same flow; Doing a data messaging back and forth would need a different approach.
@copongcopong great point, I was thinking about just starting out with implementing actions. It's still just idea stage though. Trying to think of some critical use cases.
I will be watching this issue, as I mentioned this is pretty useful for me - but I agree that use cases should be critical, will let you know if I know some very specific ones (too late at night to think about that right now :)). Checking out the other issues now to see if there is something that I can help out with over the weekend.
This feature is coming soon. Just updating here with a bit of more info on how it's implemented so we can document it:
This feature allows a web container to reach outside of its own sandbox and call its parent Jasonette native app's JASON actions, simply by calling:
JASON.call(/****JASON ACTION****/)
from its javascript. You just need to pass the same action JSON as an argument. Here's an example:
{
"type": "html",
"text": "<html><script>var t= {name: 'cat'}; JASON.call({trigger:\"add\",options:t})</script></html>"
}
Another example:
{
"type": "html",
"text": "<html><script>JASON.call({type:\"$util.alert\",options:{title: 'alert', description: 'this is an alert'}})</script></html>"
}
This is part 1 of the full IPC architecture as it addresses only the webcontainer ==> Jasonette
direction communication.
The part 2, which is the opposite direction (Jasonette ==> web container
), is much more complicated and involves introduction of multiple APIs since it needs ways to describe how to:
- Identify each web container component with a unique identifier
- Keep track of all the web containers that can be messaged
- Dispatch a Javascript function call to only the intended web container
Part 1 is already useful for many cases and it looks like Part 2 will take some time to figure out, which is why it's broken down into two parts. The part 2 will be a separate PR.