Calling Developers!
We are reenergizing our code contribution process! Learn More

What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hi dear community! We would like to hear your opinions on an RFC (that is inside the thread) in orde

Options
Valerii Trots
Valerii Trots SRE @ Spryker Sprykee Posts: 1,654 ✨ - Novice

Hi dear community!
We would like to hear your opinions on an RFC (that is inside the thread) in order to understand if it makes sense to invest time into it. Please either put +- as reaction if it's needed or not or comment in the thread.
Thank you for your feedback!

Comments

  • Valerii Trots
    Valerii Trots SRE @ Spryker Sprykee Posts: 1,654 ✨ - Novice
    edited January 2021
    Options

    RFC: Value objects in Transfers

    We had a few important steps last year to make transfers more type-safe, more consistent.
    We so far do not yet have value object support built in.

    Reasoning
    With timezone relevance, we are customers might soon be interested to transport datetime values as such objects, rather than plain strings as it is now.
    It also makes display in the correct timezone and localization in the right language/syntax easier, if the VO supports this.

    E.g. Cake\Chronos\Date (https://github.com/cakephp/chronos/blob/master/src/Date.php )

    We currently use decimal as native type using internal Spryker\DecimalObject\Decimal class.

    But we could just as well think about many use cases a VO would be better suited than pure scalar or array values, that then need to be processed by template helpers or custom business logic all over the place for simple operations as well as printing out.

    Examples:
    *Coordinates
    *Enums
    *Color, Paint, hex or otherwise
    *Money ⚠
    *IPAddress/Web/Identity

    See for example https://github.com/cultuurnet/valueobjects

    Syntax
    Always a FQCN string with leading \ to make sure this is not a transfer name:
    <field name="lastLogin" type="\Cake\Chronos\Date"/> as immutable datetime VO

    Implementation

    elseif (!empty($this->_metadata[$field]['isClass']) && !is_object($value)) {
        $value = $this->createWithConstructor($field, $value);
    }
    

    So based on the isClass detection and the type being that class, we just need

    return new $class($value);
    

    Requirement:

    $y = fromArray(toArray($x))
    $x === $y

    In order for the to array / from array part to work, any VO that cannot use scalar constructor value must implement a FromArrayToArray interface, and the building of the object would then use e.g.

        /**
         * @param array $config
         *
         * @return string|null
         */
        protected function detectSerialize(array $config): ?string 
        {
            $serializable = is_subclass_of($config['type'], FromArrayToArrayInterface::class);
            if ($serializable) {
                return 'FromArrayToArray';
            }
    
            $jsonSafeToString = is_subclass_of($config['type'], JsonSerializable::class);
            if ($jsonSafeToString) {
                return null;
            }
    
            if (method_exists($config['type'], 'toArray')) {
                return 'array';
            }
    
            return null;
        }
    

    For scalar representation we cannot assert an interface and need to trust the value object to handle this properly. This is the responsibility of the dev here to make sure only such VOs are used.
    This is especially important with existing VO like the ones linked above, as we cannot easily make them “implement” any such interface. We could only extend on Spryker/Project side and require those wrapper libs to be used. But this often doesn’t work with the VO itself on e.g. cloning returning the vendor instance instead of the wrapper one. So best to not address this and opening up more issues.

    BC
    no BC issues here, it would fully work and exist beside the current “Transfer” names, as those do not start with FQCN \ string.

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    Thanks for looking into this area! Have been longing for that for years 🙂

  • Ahmed Sabaa
    Ahmed Sabaa Senior Application Architect @Spryker Sprykee Posts: 54 🧑🏻‍🚀 - Cadet
    Options

    If you’re reacting with a yes, it would also be helpful to know what use case you have for such feature 🙂