Not possible to deserialize a subset of Slate value

[e1himself]

There is API to deserialize the whole slate value with Unserializer, but you cannot deserialize a single Mark or Leaf.

Mentioned by @spawnia in #16 .

[e1himself]

@spawnia can you please elaborate on this more? Why do you need it?

[spawnia]

Hey @e1himself we did use it for testing purposes.

We generate formatted text from our application code and want to assert it is equal to what our frontend editor spits out.

This enables us to simply copy-and-paste parts of the manually generated value into our test code and use it to build the expected outcome.

[e1himself]

@spawnia can you please provide an example of such a test so I better understand the use-case?

[spawnia]

$this->assertJson(
    Paragraph::fromJSON(/* JSON i copy-and-pasted out of a frontend-side editor */),
    $someAutomaticallyGeneratedText
)

[e1himself]

@spawnia

Can you please provide a real test code please?

The one you've pasted above does not make sense. As $this->assertJson(...) does assert if the argument is a valid JSON string:

https://github.com/sebastianbergmann/phpunit/blob/master/src/Framework/Assert.php#L2611-L2620

    /**
     * Asserts that a string is a valid JSON string.
     *
     * @throws ExpectationFailedException
     * @throws \SebastianBergmann\RecursionContext\InvalidArgumentException
     */
    public static function assertJson(string $actualJson, string $message = ''): void
    {
        static::assertThat($actualJson, static::isJson(), $message);
    }

I'm sorry for insisting, but I really want to understand the use-case and make sure there's no other way to achieve the same without BC-breaking the API.

[spawnia]

@e1himself you are correct about the example i posted, it does not make sense and does not illustrate my point.

We do have code that autogenerates bits of Slate-formatted values. Sometimes, it spits out
a Paragraph, other methods generate a Text.

Next step is that those generated bits are persisted in the database, so we have to serialize them.

Finally, we get the values back from the database and have to work with them programatically - do some filtering, apply different formattings, etc. - and then combine them into a full Value.

With the current API, we would have to wrap every single bit we want to persist in a Value just to be able to deserialize it later.

[e1himself]

Hello @spawnia 👋

I've been thinking about this use-case since you've first posted it here. I didn't reply because I didn't have a good answer yet.

Now, after the release of Slate v0.46, I believe it's a bad idea to serialize/deserialize nodes in separate.

Slate JS has dropped the Leaf model, merging its properties directly onto Text nodes. Which does make a lot of sense. But what do you do now with all the stored Leaf objects?

So we've faced the need to migrate our application code and all our stored content to the new structure. After thinking on the best way forward we've decided to separate the Slate PHP model from the serialization format. So now serialized JSON structure it's not a 1-to-1 "json-izaton" of PHP objects, but is just one of variants of string serialization.

Now this library does support serialization and deserialization for multiple Slate JSON versions, making it possible to gradually migrate database content to the new Slate version. At the moment of writing this, prezly/slate-php does support three (slightly) different JSON serialization formats (and can be extended to more in future):

• v0.27 ... v0.39 — block nodes with isVoid property
• v0.40 ... v0.45 — isVoid dropped
• v0.46 ... ? — leaf objects are not used anymore

This helps us to disconnect Slate backend model upgrade from Slate frontend package.

So now we can have Leaf model dropped in backend, keeping the previous serialization format with leaf objects, until the frontend is upgraded.

In regards to your initial request — I still don't know a good way to handle it. Probably, the best solution for you would be to have your own Serializer implementation that can serialize/deserialize individual nodes. However, I believe it's not an optimal solution, as it would be very difficult for you to migrate your content to follow the Slate JS library updates as they are released. I'd recommend you to store slate values as a whole, if possible.

Best regards,
Ivan.