Implement toString feature

[nfdz]

Status

READY

Breaking Changes

NO

Description

I implemented the toString method feature using the props.

I think it is a very useful feature for testing and debugging that most of developers that use this library would like to use. It could be able to do this through an own subclass of equatable or another library but I think that it is overkill for this small feature. This library override already that method and there is no impact implementing this.

Related PRs

No related PRs.

Todos

There is no TODOs

• Tests
• Documentation
• Examples

Impact to Remaining Code Base

This new feature will not have impact in the code base, functionality or performance.
It is disabled by default and does not force the user to do changes.

[codecov-io]

Codecov Report

Merging #45 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #45   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           3      3           
  Lines          45     45           
=====================================
  Hits           45     45

Impacted Files	Coverage Δ
lib/src/equatable_utils.dart	100% <100%> (ø)	⬆️
lib/src/equatable_mixin.dart	100% <100%> (ø)	⬆️
lib/src/equatable.dart	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bb1723b...b0e4a3f. Read the comment docs.

[winterDroid]

Would it be possible to provide also the names for the props to make the toString() more readable?

[nfdz]

Would it be possible to provide also the names for the props to make the toString() more readable?

We do not have the name of the props. We could do a workaround and provide these labels if we see it necessary.
However, looks like this feature (the whole toString feature) is not interesting for the users and codeowners of this project, so probably it is not going to be merged. @winterDroid @felangel

[felangel]

Hey @nfdz! Sorry for not having taken a look at this PR. I will review it shortly 👍

[jaripekkala]

I would love to see the prop names as well. Maybe something like this

mixin NamedProps on Equatable {
  @override
  get props => this.namedProps.values.toList();
  
  Map<String, Object> get namedProps;
  
  @override
  toString() => '$runtimeType$namedProps';
}

Usage

class User extends Equatable with NamedProps {
  final String name;
  final int age;
  
  @override
  get namedProps => {'name': name, 'age': age};
  
  User(this.name, this.age);
}

print(User('Foo', 24)); // User{name: Foo, age: 24}

[nfdz]

@felangel Thank you very much for the feedback. I have implemented all the suggestions.

About this:

Might want to have a check for if is props is null.

My first implementation was with this check. However, I saw that the hashCode method failed in the tests that I wrote to test null props, so I thought we had the assumption that props would never be null.

I rewrite the code checking nulls, the tests and also fix the hashCode method.

[nfdz]

I would love to see the prop names as well. Maybe something like this

mixin NamedProps on Equatable {
  @override
  get props => this.namedProps.values.toList();
  
  Map<String, Object> get namedProps;
  
  @override
  toString() => '$runtimeType$namedProps';
}

Usage

class User extends Equatable with NamedProps {
  final String name;
  final int age;
  
  @override
  get namedProps => {'name': name, 'age': age};
  
  User(this.name, this.age);
}

print(User('Foo', 24)); // User{name: Foo, age: 24}

@felangel do you have thoughts about this? Maybe we should study this in another PR.

[felangel]

LGTM 👍
Thanks so much for the contribution and sorry for the delayed PR review!

[felangel]

I would love to see the prop names as well. Maybe something like this

mixin NamedProps on Equatable {
  @override
  get props => this.namedProps.values.toList();
  
  Map<String, Object> get namedProps;
  
  @override
  toString() => '$runtimeType$namedProps';
}

Usage

class User extends Equatable with NamedProps {
  final String name;
  final int age;
  
  @override
  get namedProps => {'name': name, 'age': age};
  
  User(this.name, this.age);
}

print(User('Foo', 24)); // User{name: Foo, age: 24}

@felangel do you have thoughts about this? Maybe we should study this in another PR.

Yeah I'd discuss that in a separate issue. I feel like at that point it's easier to just override toString manually haha. Would love to hear what everyone else thinks.

[nfdz]

LGTM 👍
Thanks so much for the contribution and sorry for the delayed PR review!

No worries! Glad to help the project