Consider adding `Actor.use_state`

[Pijukatel]

Context: apify/apify-docs#2176 (comment)

[B4nan]

IMO nothing to consider here, this is missing, it should be here, let's add it asap so we don't block that docs PR.

[B4nan]

@Mantisus can you look into this please?

[Pijukatel]

It has to take this into account apify/crawlee-python#1669

Given the discussion here apify/crawlee-python#1669 (comment)
the Actor.use_state should access the same state as the first default crawler. So key CRAWLEE_STATE_0 (depends on the implementation there)

[B4nan]

Huh, I should have checked this before, but we apparently use different default state keys in the SDK and in crawlee, so what I was highlighting here (mismatch between the SDK and context version) is not really a problem.

https://github.com/apify/crawlee/blob/master/packages/basic-crawler/src/internals/basic-crawler.ts#L491
https://github.com/apify/apify-sdk-js/blob/master/packages/apify/src/actor.ts#L1593

Now I'm not so sure if we should share the default key, I saw it as a nasty BC, but if it didn't work like that before, I guess we should keep the current JS behavior, so keep different default state keys for SDK and BasicCrawler.

Thoughts @barjin @janbuchar @Pijukatel?

[barjin]

Given we want to split the Crawlee state to have a separate one for each Crawler instance, it doesn't really make sense to me to add SDK support on top of this.

JS and Python SDK sharing the same state (key) on Actor.useState / Actor.use_state sounds nice and IMO sells the idea it's actually the "Actor's state", not some random KVS value.

[B4nan]

it doesn't really make sense to me to add SDK support on top of this.

Care to elaborate? It sounds like you don't want to have Actor.useState at all, but I am sure that's not the case?

---

Right now I am inclined to keep the JS behavior, with a fixed SDK state key, and do the same in Python, so Actor.useState in JS uses the same state key as Actor.use_state in Python.

[Mantisus]

I favor using different base keys for use_state in Crawlee and SDK. And accordingly, using the same key APIFY_GLOBAL_STATE in Python and JS.

These are different entities, and as a user, I would expect the data in use_state to be associated only with a specific entity.