You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 15, 2023. It is now read-only.
Right now, there are 5 object handling approaches: Error, Array (including iterators and Arguments), Map, Set, and Pojo (plain old JavaScript object, which includes all other object classes).
Let's say I wanted to format some particular type of object in a particular way. (For example, a React component instance, as mentioned in #3.) The process of adding that would involve writing the requisite tree-walking printing logic in Format, and implement it with extension points that can be overridden to turn that printing walk into a comparison-and-dual-printing walk in Same, and override whatever parts of that comparison walk that need to differ in the other child classes. (Typically, this just means overriding something in Has, since the others all either follow the walk process from Same or Has, depending on whether they require all fields to be present, and then swap out the test method for simple comparisons.) Also, implement the three entries in the styles object to print all the different things that might need to be printed for that sort of thing.
Kind of a lot of stuff to do!
In the spirit of "make the hard thing easy, then do the easy thing", maybe it'd be worth having some kind of "collection type plugin" approach so that it's easier to add a new strategy for a new object type?
The argument for it is that it'd be easier to add new collection types.
The argument against is that most objects are probably pretty much like one of those (even the Error handling is basically just pojo but with some special handling for name and message, since almost all Errors have those, and there's a customary way to print the first line as ${name}: ${message}). Most objects in JS are array-like (ordered keyless), set-like (unordered keyless), map-like (orderless complex keys), or pojo-like (orderless simple keys). So any new object will probably just be a matter of jumping on one of those 4 styles and adding a few style methods.
And how often do we get new object types in JS? I mean, yeah, JSX elements would be nice to print cleverly. I could also see wanting to print Request and Response objects in a nicer way (right now they just end up in the pojo category). But beyond that?
I think I maybe just talked myself out of it. I'll leave this issue up for a while though, in case any other ideas or requests come up.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Right now, there are 5 object handling approaches: Error, Array (including iterators and Arguments), Map, Set, and Pojo (plain old JavaScript object, which includes all other object classes).
Let's say I wanted to format some particular type of object in a particular way. (For example, a React component instance, as mentioned in #3.) The process of adding that would involve writing the requisite tree-walking printing logic in
Format
, and implement it with extension points that can be overridden to turn that printing walk into a comparison-and-dual-printing walk inSame
, and override whatever parts of that comparison walk that need to differ in the other child classes. (Typically, this just means overriding something inHas
, since the others all either follow the walk process fromSame
orHas
, depending on whether they require all fields to be present, and then swap out thetest
method for simple comparisons.) Also, implement the three entries in thestyles
object to print all the different things that might need to be printed for that sort of thing.Kind of a lot of stuff to do!
In the spirit of "make the hard thing easy, then do the easy thing", maybe it'd be worth having some kind of "collection type plugin" approach so that it's easier to add a new strategy for a new object type?
The argument for it is that it'd be easier to add new collection types.
The argument against is that most objects are probably pretty much like one of those (even the
Error
handling is basically just pojo but with some special handling forname
andmessage
, since almost all Errors have those, and there's a customary way to print the first line as${name}: ${message}
). Most objects in JS are array-like (ordered keyless), set-like (unordered keyless), map-like (orderless complex keys), or pojo-like (orderless simple keys). So any new object will probably just be a matter of jumping on one of those 4 styles and adding a few style methods.And how often do we get new object types in JS? I mean, yeah, JSX elements would be nice to print cleverly. I could also see wanting to print
Request
andResponse
objects in a nicer way (right now they just end up in the pojo category). But beyond that?I think I maybe just talked myself out of it. I'll leave this issue up for a while though, in case any other ideas or requests come up.
The text was updated successfully, but these errors were encountered: