Multi-threading, concurrency, agents

[therustmonk]

This is a series of bold experiments and I really love 💓 this PR.
It makes this framework a multi-threaded (it's not a joke) and brings actors model everywhere.
Now your yew frontend-apps will be more Erlang or Actix apps like 🚀

Also, I've removed a context. Completely! Components simplified. Now it's an actor which you could connect to and interact with messages.
Other benefit is your components could interact each other #270

Since this PR will be merged the framework turned into multi-threaded concurrency-friendly frontend framework. Sorry me for buzzwords overload )

It still need Routing #187 and fixes of the most issues. I'll get to that.
But extra benefit of this PR: it fixes major emscripten issues #220

Remaining:

• Add CHANGELOG.md
• Update README.md
• Create issue: Send Connected notification for Private agents (Send Connected notification for Private and Public agents #282)
• Create issue: Send Connected notification for Public agents (Send Connected notification for Private and Public agents #282)
• Create issue: Implement Global kind of agents (based on SharedWorker) (Implement Global kind of agents (based on SharedWorker) #283)
• Create issue: Add components interaction example (Add components interaction example #284)

[kellytk]

Would it be feasible to utilize actix in Yew for this?

[therustmonk]

@kellytk I've tried to use actix in the first attempt, but it tied with tokio and uses a little different approach.
I tend to make it similar and consider future utilization of actix here.

[fafhrd91]

@deniskolodin just FYI, i am planing to split actix into two packages. actix-core will depend on only on futures. and actix will provide tokio integration.

[therustmonk]

@fafhrd91 Thank you for bringing Erlang world to Rust! I like it! 💪

I use your framework a lot and it will be great to make some improvements for make it suitable for this framework. I replaced a context with a link to an environment. I feel it's better, because developer doesn't need to carry the reference everywhere.

For me it also will help to use the same code for different parties. Regarding actix: websocket client differs from websocket server. The first uses field to send messages, the second uses a context. I felt the same jaggies with my framework and finally, I've replaced a reference with a premanent link:

Before:
https://github.com/DenisKolodin/yew/blob/a81c8538e0d2a91aea83ca47975bd443017f596e/examples/counter/src/lib.rs#L30

After:
https://github.com/DenisKolodin/yew/pull/272/files#diff-fc7dcdea47d4c57ee595a5ea0a50aabcL30

Anyway I used some similar structs like actix, Envelope for example:
https://github.com/DenisKolodin/yew/pull/272/files#diff-c5e60eebb9e4be94e8b7f79670c6acacR598

Thank you for the information about actix split! I'll try to help you with ideas and PRs. And if you will take into account this framework for making actix-core I could use your framework for actors basics.

[fafhrd91]

I can not remove Context, it is required for different types of actor. But I really like idea with ComponentLink.

[kellytk]

@deniskolodin the changes introduced here appear to move Yew towards an ECS design, is that correct?

[therustmonk]

@kellytk It's similar to ECS approach, but actually it closer to CSP. Like with Erlang: a process is not an entity of "physical world", but it an entity who does part of its job. In other words: the actor is not an a record in a database, it's a handler which services database interaction completely.
If you mean "could you use it for gaming abstractions", I think it's better to create tiny structs inside actor for handling gaming entities.

[therustmonk]

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[kellytk]

@deniskolodin

but it tied with tokio

FWIW I've found Riker, which apparently is not coupled in that way.