Binding System 2
  • Welcome
  • Product
    • Binding Values
    • Minimal UI
    • Pinning Fields
    • Extending the System
      • Bind Class
      • Converters
      • Modifiers
        • List of Available Modifiers (WIP)
      • Bind Rerouting
      • Accessor Providers
    • Demo
    • Settings
    • Troubleshooting
      • Errors Visualization
      • Live Debug
      • Path Value Preview
      • Refactoring
      • Bindings Dependencies
    • Reserializer
    • Performance
    • FAQ
    • External Extensions
      • Odin Inspector
    • ‼️Upgrading from Version 1
  • Change log
    • Changes from version 1
  • Third Party Licenses
Powered by GitBook
On this page

Was this helpful?

  1. Product
  2. Troubleshooting

Refactoring

PreviousPath Value PreviewNextBindings Dependencies

Last updated 4 months ago

Was this helpful?

Available from version 2.1.1

Refactor System is a tool which helps mitigating issues arising from changing the structure of types, either by removing members, or simply by renaming them. Without this system, all related bindings would become corrupted.

To better explain this, let's play with a toy example. Suppose you have the following script:

public class Shield : MonoBehaviour
{
	public string shiledType;
	public float damage;
	public float optionalDamage;

	// Logic follows
}

Now if you notice, there are some issues with this script.

  1. There is a typo for the first member shiledType, should be shieldType.

  2. The shield doesn't require a damage member, but rather a health one.

  3. The field optionalDamage may not be needed, and the developer decides to remove it.

Now let's suppose we bind each field and then apply all the changes above. We will end up with the following:

public class Shield : MonoBehaviour
{
	public string shieldType;
	public float health;
	
	// Logic follows
}

In previous versions, all this process will lead to all bindings becoming corrupted and most probably will spam the console. Here's where Refactor System kicks in to intercept these changes and just before invalidating the bindings, will ask the user how to proceed with each change. Here's the popup window that will be presented to the user:

All three changes will be shown, with the number of affected bindings (only in assets and currently loaded scenes) and options on how to proceed. The options are either to replace the fields with new members, or to remove all affected bindings. Here's the situation after the change:

When clicking on Apply All, the changes will be stored in a special changes history file and each binding affected by these changes, will be updated once it becomes available. This means all bindings in assets and currently loaded scenes will be updated immediately, and all other bindings will be updated automatically when their respective scenes will be loaded.

Here's the final result without doing any manual work:

In next versions, the Refactor System will evolve and will treat refactoring from bound sources as well, which currently only notify the user about a missing member.

Bound Fields of Toy Example
Dialog Popup of Intercepted Code Changes
Dialog Popup with decided follow-ups