Immutable or Mutable data model, which should be used for designing the software like google form, google doc etc.?

Viewed 1166

We are developing a software which would be write extensive as well as memory extensive in Flutter. And it would also support undo and redo features. Currently we have zero experience in immutable data structure. During the research of flutter, I came up with the freezed package, code generator for immutable data model, which motivated me to understand the immutable data set. But using of immutable data model giving various challenges like -

  1. Updating of deeply nested children of the data model
  2. Deep copying of whole data even on a minor change in any of the nested data model(Like a letter change in the google doc), would make our application slow.
  3. We were planning to keep multiple copy of the the same model for supporting the undo or redo, but this will take a lot of memory space of the end user.
1 Answers

Updating of deeply nested children of the data model

Since you are using Freezed, this should not be a problem. Freezed offers a built-in mechanism for updating deeply nested variables

https://github.com/rrousselGit/freezed#deep-copy

For example, assume that you have:

@freezed
abstract class Company with _$Company {
  factory Company({String name, Director director}) = _Company;
}

@freezed
abstract class Director with _$Director {
  factory Director({String name, Assistant assistant}) = _Director;
}

@freezed
abstract class Assistant with _$Assistant {
  factory Assistant({String name, int age}) = _Assistant;
}

Then that instead of:

Company company;

Company newCompany = company.copyWith(
  director: company.director.copyWith(
    assistant: company.director.assistant.copyWith(
      name: 'John Smith',
    ),
  ),
);

You can write:

Company company;

Company newCompany = company.copyWith.director.assistant(name: 'John Smith');

Deep copying of whole data even on a minor change in any of the nested data model(Like a letter change in the google doc), would make our application slow.

When using immutability, there are very few reasons to make a "deep copy". Instead it is a shallow copy that is performed.

To continue on the Company example, assume that you have:

var company = Company(
  name: 'Google',
  director: Director(
    name: 'John',
  ),
)

Then when you want to change the company name, you'll only need to do:

company = company.copyWith(name: 'Facebook');

When doing so, the Director is not recreated. Only the Company is, which is a lot more efficient.

It's fine since Director is immutable. We can't change anything on Director, so there is no risk of conflict even if two objects are using the same Director.

We were planning to keep multiple copy of the the same model for supporting the undo or redo, but this will take a lot of memory space of the end user.

Continuing from the previous point, what you will store is not deep copies, but shallow copies.

So in the end the memory impact is reduced by a lot.

And as you mentioned undo-redo, even if you didn't use immutable data, chances are you'd still use that memory.

Related