What a smooth and smart presentation. Boy Google is lucky to have you, Paul Irish, Jake Archibald and many more :-)
@johnbalvin54015 жыл бұрын
boy they are not Paul Irish and Jake Archibald, they are Paul Lewis and Surma
@Textras5 жыл бұрын
first Actor :) Thinking the media, security, device capabilities and identity being only exposed on the main thread 'is a bug' means there's hope. Free the API's!!
@samirsaeedi745 жыл бұрын
22:55 are we talking interfaces? (TS has them them.) Maybe throw in a dependecy injection mechanism there while you're at it. Also I don't get the desire to send messages to have the actor choose the right method to call (possibly in a somewhat redundant switch case construct). Why not just call the method directly? If the interoperabolity between different implementations is the concern then interfaces have you covered already. I guessI have to read about the pattern more.
@dassurma5 жыл бұрын
Yeah, we are talking interfaces, but rather message interfaces than method interfaces. The reason messages are kinda more preferable is because they are usually easier to serialize to other communication channels. But in the end you are right, it’s all just semantics. As you can see in the examples in the `actor-boilerplate`, I did in deed ditch the switch-case for a direct function invocation: github.com/PolymerLabs/actor-boilerplate/blob/92d986dde57f2269ca9a0351da79fd7584c6abc8/src/actors/storage.ts#L60 As for Dependency Injection, that’s pretty much what hookup/lookup are, just not injected as parameters (you can build that as a layer on top, if you want).
@SeanJMay5 жыл бұрын
You won't be able to call the method of an object that is on the server, or exists in a different thread. I realize that's what RPC was all about, but I hope that most of us agree that was a generally not-great idea, which lead to bugs and vulnerabilities. The actor model was based on Carl Hewitt playing pool, and observing how all of the balls interacted with one another on the table. It works like this: I am an actor. I have an inbox. People who have my address know that I will only accept certain kinds of requests. At some point, I will be allowed to pull the first message from my inbox, read it, and perform some action. During that action, I might compute some value, I might send a message to somebody else's inbox (assuming I know their address), I might instantiate another actor (and thus have their address), or I might just decide to do nothing. At some point in the future, I will be allowed to check my inbox again. The reason this works across threads and networks is because the interfaces are for data-interchange, and not for class instances. No RPC required. The actors don't even need to be written in the same language, if the framework is sufficiently awesome.
@davidjournot17415 жыл бұрын
Very useful presentation, thank you! I've been playing around with angular platform-webworker for a while to bring as much code to the webworker as possible but this solution lacks flexibility for importing libraries or lazy loading. I might switch to the actor model.
@RuairiODonnellFOTO5 жыл бұрын
How is this different from the dispatcher within something like Redux?
@davidkhourshid44505 жыл бұрын
Asking the wrong question. How is Redux different from the Actor model? ;-)
@prosperobum21855 жыл бұрын
Your making use of web workers instead
@beknaraskarov5535 жыл бұрын
Redux can be used as a state machine of an actor
@dassurma5 жыл бұрын
Well observed, it’s very much related. But Redux is just a single entity. The actor model is a generalization of this concept. You can implement the actor model with multiple Redux instances, although the cross-thread messaging will get a bit messy.
@MichaelQuad5 жыл бұрын
ye, okay, but there is no shared memory between web-worker and the main thread, how to handle thing? it's not convy to send string/ArrayBuffer messages. it will require overhead and another which will implement copy-transfer.. right?
@emilemil15 жыл бұрын
So basically the observer pattern. It's a good model for anything with a responsive UI, though it has the issue of allowing frames to slip between the cracks. You have to take great care to batch your DOM updates so that you don't get frames with half-finished modifications. A simpler way to improve performance would be to have "checkpoints", basically places where you say that it's okay for your JS execution to pause. It could either be a short pause that allows only a single frame (for animations), or it could also allow reflows if future JS won't modify the DOM. Basically you tell the browser to temporarily make rendering JS-blocking, rather the other way around. The main advantage of this method is that it is pattern-agnostic and backwards compatible. Just toss in a few checkpoints in problematic areas and it just works.
@212astra5 жыл бұрын
where's the supercharged T_T
@datsteves3 жыл бұрын
i actually build my own package for that because of this presentation :D which we use in our new app at work that we will roll out in to production soon :) split it up even further though, that anyone in the system can talk to a single component in the UI. so for example you can have a long running task in a worker (maybe even on the a worker_thread via electron) that yields every few seconds its progress to a process manager ui component that will display that state. Or simpler, any button, hotkey or command palette component could say "open edit task edit modal with ID: 123". This helped a lot, as we now can move the upload process, the thumbnail generation and so on to a webworker, without having to change almost anything. just the bit that connects the two systems has to be a little different. Which is just like 2-3 lines of code :D you can even query things from those actors, if you await an dispatch and the actors responds to the message you get that value back, which is nice :) anyone who is interested can look at github.com/datsteves/actorize its still more like in an alpha version, so apis can change and probably will, as we at work get more experience at working with that package with what works and what doesn't. Thats why for example there is a React hooks integration :)
@cucco15 жыл бұрын
Really looking forward to try some implementations of this.
@dassurma5 жыл бұрын
Well, then go take a look at github.com/PolymerLabs/actor-boilerplate
@cucco15 жыл бұрын
@@dassurma Neat! That was an interesting and well done presentation. Any chance we might see frameworks like Angular implement aspects of this model?
@davidrivers76675 жыл бұрын
Watching with Grace my daughter 7yrs old who designs PWA apps for kids
@UliTroyo5 жыл бұрын
Pieter Hintjens was the first person from whom I heard of the actor model and state machines. R.I.P.
@danbilokha3 жыл бұрын
Love it, thank you guys
@VladimirBrasil5 жыл бұрын
Very engaging project. Huge congrats. At the 11:36 slide switch(this.state.value) is used inside onMessage to handle state transition. This is the "coupled way" to use xstate, as shown at statecharts.github.io/how-to-use-statecharts.html#decouple-the-component-from-the-statechart Do you have any opinion about using the decoupled versus the coupled way when you need to build the relation between components and the statechart? In a decoupled scenario, this.state (xstate, statechart) would explicitly tell the component what to do, using the actions/activities capabilities built into xtate/statechart. At what measure do you think this is not a good idea? Or is a good idea? What about guards - also a capability built into xtate/statecharts? Do you think your very engaging new way of thinking would benefit from letting the state use guards? If I want the non-ui components to be easily changeable, and also the statechart to be easily changeable, this.state leaking into the Clock component - inside switch(this.state) - could be a increasing mess to manage, couldn't it? Where am I wrong? What am I misunderstanding? A scenario: if I wanna change the statechart, changing a state name, I probably need to change clock.js as well. Is this an issue? Even for a big project? Can we facilitate this scenario of changing a state name when the project is already big enough? I am all ears, hoping to learn where I am wrong, because I can foresee that you already thought about this scenarios, it’s only me that am a little bit yet confused (sorry for my possibly silly questions, in advance!).
@abaidooprince98133 жыл бұрын
can somone help with how this could be implemented with vue and vuex
@cedpoilly5 жыл бұрын
Love it!
@RahulPradipPatil5 жыл бұрын
Amazing.. useful
@JoshuaMoreno5 жыл бұрын
So is Paul back?
@AlessandroMenduni5 жыл бұрын
My God, does this mean I oughta reopen Twitter? Paul was the only reason I used to connect (well that was a bit over the top)
@malipetek5 жыл бұрын
I appreciate 60fps
@B1FREQUENCY5 жыл бұрын
Please Talk about How to Remote Control via Threads to Turn on DEVICE COMPONENTS....PRIME EXAMPLE...."HOW TO TURN ON FACE CAMERA"
@Booyamakashi5 жыл бұрын
Is this redux under different name?
@saa4425 жыл бұрын
I felt the same. exactly
@aammssaamm5 жыл бұрын
It's jquery.trigger under different name :)
@amitkarmacharya44932 жыл бұрын
The back and forth between the speakers was reallyannoying.
@neilsumanda15383 жыл бұрын
i admit.. when they said "RUsh Hour" i thought they are talking about the movie...
@nando40705 жыл бұрын
:D
@davidjournot17415 жыл бұрын
Very useful presentation, thank you! I've been playing around with angular platform-webworker for a while to bring as much code to the webworker as possible but this solution lacks flexibility for importing libraries or lazy loading. I might switch to the actor model.