Gavin/sta 3984 blog post on what is the actor model and when should i use

[gavination]

No description provided.

[linear]

STA-3984

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
blog	✅ Ready (Inspect)	Visit Preview	Jun 2, 2023 1:20pm

[laurakalbag]

@gavination you’re a great writer! This is brilliant. I’ve made a few small suggestions. I also took the liberty to update the straight quotes ('/") to curly quotes (‘”) via a commit.

Do you think we should link up some of the XState concepts to their relevant pages in the new docs? (V5-specific docs are at https://stately.ai/docs/xstate-v5)

I was wondering if we should provide code examples for both XState V4 and XState V5 here? (We could do this with a tabbed interface in the new blog, see below.) cc @davidkpiano

Once this is ready, we should also look into porting it to the “new” blog (inside the docs) as those will be launched soon!

[laurakalbag]

Suggested change

The actor model has been around for quite a while, dating back to the 1970's. That it's used with frameworks like [Akka](https://akka.io/) and built natively into languages like Erlang(https://www.erlang.org/) are testaments to its utility. When researching the actor model, it's very common to see the phrase "everything is an actor", as it is a core tenant in the actor model philosophy. This simply means that in a given system, the _actor_ is the core unit of execution. Every action that occurs in the system is driven by an actor. An actor can communicate with other actors with the use of messaging, and they can also interact with external systems. Specifically, an actor can perform the following basic tasks:

The actor model has been around for quite a while, dating back to the 1970's. That it's used with frameworks like [Akka](https://akka.io/) and built natively into languages like [Erlang](https://www.erlang.org/) are testaments to its utility. When researching the actor model, it's very common to see the phrase "everything is an actor", as it is a core tenant in the actor model philosophy. This simply means that in a given system, the _actor_ is the core unit of execution. Every action that occurs in the system is driven by an actor. An actor can communicate with other actors with the use of messaging, and they can also interact with external systems. Specifically, an actor can perform the following basic tasks:

[kevinmaes]

@gavination you’re a great writer! This is brilliant. I’ve made a few small suggestions. I also took the liberty to update the straight quotes ('/") to curly quotes (‘”) via a commit.

Do you think we should link up some of the XState concepts to their relevant pages in the new docs? (V5-specific docs are at https://stately.ai/docs/xstate-v5)

I was wondering if we should provide code examples for both XState V4 and XState V5 here? (We could do this with a tabbed interface in the new blog, see below.) cc @davidkpiano

Once this is ready, we should also look into porting it to the “new” blog (inside the docs) as those will be launched soon!

I like the idea of adding the v4/v5 tabbed examples in general. One other reason that comes to mind for spawning actors is that I found the signature of spawn() to be confusing from the v4 documentation because the 2nd argument can be either a string name or an options object (not sure I saw if that's clearly stated or just implied by various examples). It seems like in v5 this 2nd arg is always an object with an id property. Is this accurate @Andarist @davidkpiano ? Having both examples clearly labeled v4 vs v5 might help to clear this up for readers.

[davidkpiano]

Let's avoid mentioning sync: true, this is going away in v5

[farskid]

I can argue message passing is explicitly asking for a state change.

[davidkpiano]

I can argue message passing is explicitly asking for a state change.

Hmm, messages don't always result in a state change though, nor is that the concern of the message sender. When a message is received, effects may be executed as a result, but those effects don't need to result in a state change.

[farskid]

Sure. I was emphasizing on the "explicit vs implicit".

[davidkpiano]

Suggested change

	const todosMachine = createMachine({
	// ...
	on: {
	"NEW_TODO.ADD": {
	actions: assign({
	todos: (context, event) => [
	...context.todos,
	{
	todo: event.todo,
	// add a new todoMachine actor with a unique name
	ref: spawn(todoMachine, `todo-${event.id}`, { sync: true }),
	},
	],
	}),
	},
	// ...
	},
	});
	const todosMachine = createMachine({
	// ...
	on: {
	"NEW_TODO.ADD": {
	actions: assign({
	todos: (context, event) => [
	...context.todos,
	// add a new todoMachine actor with a unique name
	spawn(todoMachine, `todo-${event.id}`),
	],
	}),
	},
	// ...
	},
	});