search

cathei / AntiScriptableObjectArchitecture

DO NOT USE ScriptableObject Architecture
19 stars 1 forks source link

Reason 7. is wrong. #3

Open soraphis opened 2 years ago

soraphis commented 2 years ago

https://github.com/cathei/AntiScriptableObjectArchitecture/blob/11f7e65f406e86f5d4436018728f98c74ec6a5e0/README.md?plain=1#L27-L28

This has nothing to do with domain reload. In the editor ScriptableObjects always kept their values - not so in builds.

IIRC on UnityAtoms we addressed the issue and are resetting the ScriptableObjects accordingly event if domain reload is disabled. Not sure if we handled every edge case, but it surely is possible to do so!

cathei commented 2 years ago

What I read from Unity Scene reloading document says it is relevant.

Disabling Scene Reload should have minimal side effects on your project. However, because Scene Reloading is tightly connected to Domain Reload, there are a couple of important differences:

ScriptableObject and MonoBehaviour fields that are not serialized into the build ([NonSerialized], private, or internal) keep their values. This is because Unity does not recreate existing objects and does not call constructors. Additionally, Unity converts null private and internal fields of array/List type to an empty array/List object during Domain Reload and stay non-null for runtime (non-Editor) scripts.

But you’re implying they are keeping their value regardless. Anyways, if you need to install some other plug-in or additional step for it, point still stands.

soraphis commented 2 years ago

if you need to install some other plug-in or additional step for it, point still stands.

no, you just have to code your scriptable object architecture properly (UnityAtoms, which i mentioned is a SO-Architecture library, no further plugin needed). But you also have to be careful with your MonoBehaviour scripts if you disable domain reloading.

ALSO same point stands for every other solution. You also have to create a WORKING dependency injection system, if you want to use DI instead of SO-A.

having coded something badly is not really an argument against SO-A, but is more like a general advice.

cathei commented 2 years ago

ALSO same point stands for every other solution. You also have to create a WORKING dependency injection system, if you want to use DI instead of SO-A.

That is true :)

having coded something badly is not really an argument against SO-A, but is more like a general advice.

Yes, but I mention it because it’s easier to create those errors when you use SO. MonoBehaviour usually reset their states through lifecycle events and if you use regular C# object you would just create new instance without garbage value.