carbon and morphoji

[iampersistent]

Why was carbon bumped up to ^1.22? Could it not be ^1.21?

Shouldn't morphoji be a suggestion instead of a requirement?

@alexcoffee

[ruskiyos]

A few packages in our app required carbon ^1.22
Did the iso8601 functionality break things?

StringTransformer depends on morphiji. How would you prefer to deal with it?
If we make it a suggestion, then inside StringTransformer we can only apply that functionality if "class exists".

[iampersistent]

^1.21 should still allow 1.22 to be set in your app. I have 1.21.0 set in my project because that used to be what was required by Diaclone. Unless there is a reason to move it up to 1.22, I should still be able to use the previous requirement.

IMO, that isn't a normal string conversion and handling strings with emoji or any other special display should have its own transformer.

[ruskiyos]

yea. that makes sense. do you want to put in a PR or should I do it?
@alexcoffee i think we should keep the morphiji package in our app because most people don't care about parsing emojis in their string transformer and don't want to include an additional requirement

[iampersistent]

@ruskiyos You can put in the PR, since you'll have to merge it anyway.

I think there might be an interest in having the emoji transformer, but I think it should be its own thing.

[alexcoffee]

if only there was a way to combine transformers. e.g.:

        'display_name' => [
            StringTransformer::class,            // encode/decode html entities
            EmojiTransformer::class,             // encode/decode unicode chars
            OutputOnlyTransformer::class,        // allowUntransform =  false
        ],

then we could have individual transformers doing only one job, otherwise our generic string transformer is emoji transformer which also does html entity encoding.

[iampersistent]

I've actually been thinking about that and also thinking about being able to use different combinations for how it get transformed. In my current project, I need to transform the UUID as the string output for the client side, but I need it as the hex for a different usage, but I need them as objects in an object.

[iampersistent]

We've still ended up with the emoji being a requirement for string. Also, the way the multiple transformer is working, it's not able to handle transforming a collection of strings

[ruskiyos]

Why not? If you added ArrayToStringTransformer, it takes all strings in collection and applies consequent transformers to each.