Dictionary<TKey, TValue> Support in Tri Inspector (Prototype)

[Luanrobs]

I'm experimenting with a prototype to add Dictionary<TKey, TValue> support to Tri Inspector using only Odin Serializer. The goal also started with supporting more complex types (HashSet, Queue, basically anything Odin Serializer can handle).
I'm still unsure if bringing Odin Serializer into the project is a good long-term idea, but for now it felt like the most practical way to explore this.

The drawer follows the style of Tri Inspector’s built-in drawers. I used the TableList attribute as inspiration to display dictionaries as a clean Key/Value table.

The drawer is registered via:
[assembly: RegisterTriValueDrawer(typeof(DictionaryDrawer<,>), TriDrawerOrder.Drawer)]
and I had to adjust TriDrawersUtilities to support composite generic drawers.

About serialization

Just like in Odin Inspector, you can simply inherit from SerializedMonoBehaviour to get automatic serialization.
As an alternative, I implemented a small weaver that injects the required serialization code directly into the assembly.

With this weave, you can mark a class or an individual field with [TriSerialize], and the system automatically injects implementations of ISerializationCallbackReceiver and ISupportsPrefabSerialization, similar to how SerializedMonoBehaviour works.

In my initial tests, the data persists correctly after domain reloads and scene reloads.

This is still only a prototype, the code needs cleanup, review, and more thorough testing. For now, I'm just exploring options and seeing how this could integrate naturally with Tri Inspector.

Examples:

using System.Collections.Generic;
using TriWeave;
using UnityEngine;

[TriSerialize]
public class Example : ScriptableObject
{
    public Dictionary<string, int> someDictionary = new()
    {
        {"A", 1},
        {"B", 2}
    };
}

using System.Collections.Generic;
using TriWeave;
using UnityEngine;

[TriSerialize]
public class Example : MonoBehaviour
{
    public Dictionary<string, int> someDictionary = new()
    {
        {"A", 1},
        {"B", 2}
    };
}

[Luanrobs]

I came across this older discussion (#116) while working on this prototype. Since that thread is from 2023, I wanted to ask what the current stance is regarding this topic and whether there are any plans or openness to this kind of functionality today.
Tagging @vanifatovvlad to check whether this direction would still align with the project.

For context: I’m using the standalone Odin Serializer downloaded from
odininspector.com/download#serializer
which generates its own separate namespace, so it shouldn’t cause any conflicts for users who run Tri Inspector alongside Odin Inspector.

Before continuing and preparing something that could eventually become a PR, I’d like to know if support for Odin-serialized types is something you would consider, or if this should remain strictly as an external extension.

[vanifatovvlad]

Tri Inspector was made as an editor extension on top of Unity's built-in serialization, and I want to keep it that way, as adding support for custom types requires both a significant increase of the library's architecture and the implementation of a custom serializer. Regarding the Odin Serializer, I don't think integrating it into Tri Inspector is the right decision.

Therefore, the preferred way to implement support for custom types is through an external extension. I'm ready to discuss and merge changes to Tri Inspector if something will be needed to develop such an extension (if those changes aren't too complex).

[TylerTemp]

I agree on sticking on Unity's built-in solution. Odin serialization is good, but I did hit some bugs. And their customer support is... not good... If you happen to face one, you will have zero chance to fix it.

I do use some workaround in my project to serialize dictionary in my project. The limit is: It only supports targets that Unity can serialize.

[Serializable]
public class SaintsWrap<T>{
    [SerializeField] public T value;  // For Unity supported type
    [SerializeField] public SaintsSerializedProperty valueField;  // for 
    [SerializeField] public SaintsSerializedProperty[] valueArray = Array.Empty<SaintsSerializedProperty>();
    [SerializeField] public List<SaintsSerializedProperty> valueList = new List<SaintsSerializedProperty>();
    [SerializeField] public WrapType wrapType;
}

namespace SaintsField.SaintsSerialization
{
    [Serializable]
    public struct SaintsSerializedProperty
    {
        public SaintsPropertyType propertyType;  // which type it uses

        #region General Serialization
        public UnityEngine.Object V;  // Unity Object Type
        [SerializeReference] public object VRef;  // reference type
        public bool IsVRef;
        #endregion
    }
}

With this setup, anything that is supported by Unity can be included in this struct. Which allows me to implement a dictionary that supports type:

• UnityObject
• serializable class/struct
• interface for either UnityObject or serializable class/struct
• abstract class for either UnityObject or serializable class/struct

Result: interface that supports reference type & Unity object type

Result: abstract type (reference type)

[Luanrobs]

Thanks a lot for the feedback, @vanifatovvlad, and also thanks to @TylerTemp for the insights!

After taking another look, I agree that integrating a custom serializer directly into the Tri-Inspector core is probably not the best path. The added complexity and long-term maintenance risks are very real, and keeping Tri focused on Unity’s native serialization makes a lot of sense.

I also took a look at SaintsField and, even from a quick overview, I was really impressed by how robust it looks. I’ll probably test it soon and there’s a good chance I’ll adopt it as one of my core packages alongside Tri-Inspector.

Really appreciate all the opinions shared here. Thanks again!