`toJSON` method optionally omit `fmid`s

[matthew-andrews]

@wilsonpage, @georgecrawford and I have been discussing inflation of fruitmachine views on the client and we have come to realise there may be a use case for having server side fruitmachine render json without fmids.

This is for when we want to store fruitmachine definitions in databases - and therefore long after the original html has gone away.

As you know I'm terrible at APIs but potentially we could do something that looks like:-

toJSON({ fmid: false });

Let know what you think and I will send over a pull request...

[matthew-andrews]

Maybe:-

.toJSON({
  inflatable: false // defaults to true
});

[wilsonpage]

I'm confused what the use case is for this. Can you fill me in?

[wilsonpage]

I would have thought a canonical view definition would be written in 'JSON' by hand.

var layout = {
  module: 'apple',
  children: {
    slot: {
      module: 'pear'
    }
  }
};

Then both the server and client would use this definition. It seems strange that you would store the serialied .toJSON output.

[georgecrawford]

I'd love to comment, but I don't really feel familiar enough with the project I'm afraid. I can't see which is more appropriate. Wilson - be aware that we'd store the JSON (however it was produced) including the model data - one blob for each Edition or Article in the Economist, for example. So although there would be some duplication in the database, what we'd have in effect is a web component-like semantic description of the article in its entirety, requiring only templating to be inflated into HTML. Apart from that point, I don't know the answer to your question.

@matthew-andrews - over to you.

[matthew-andrews]

I guess it boils down the question of whether you should store pure data on the client side and then duplicate the transforms that rework that data from its 'pure' form to its 'fruitmachined' form.

We take both approaches in the FT's web app - the structure is a fruitmachine-like structure. Articles and so on are in a purer data form.

The Economist makes this a bit awkward because that would mean duplicating the logic in PHP and Javascript.

I was confident last night that taking the structure-like approach for The Economist was the right thing. Now I'm not so sure :-/

[matthew-andrews]

I think we decided not to go down this approach.