Add Preview URL option to Model Settings

[lunelson]

Following up on a thread in Slack: it would be nice if Models could have a Preview URL optional setting, which could be configurable in terms of a pattern based on the Model's own fields. My suggestion would be that it also reference a Production URL setting (separate feature request), and also an optional "preview query string" (possibly also configured globally, like Production URL), so that the essential content of this field would be something like [productionUrl][previewURL][previewQuery], with the first and last parts applied automatically, and the middle part possibly using handlebar or routing style patterns, e.g.

# NB 'itemType' and 'id' refer to attributes of the model
http://my.production.url/:itemType/:id/?preview
http://my.production.url/{itemType}/{id}/?preview

[Convincible]

In other words, this would allow us to tell DatoCMS what the intended output URL is for an item within a model. Once DatoCMS knows this, in theory it can do useful things that dynamically/smartly insert links between items. E.g. when inserting a link in a Text field, instead of requiring the user to know and type the URL, it can offer a link picker (#20). This would avoid clients creating broken links.

You would definitely want to include something like: {parent:slug} or {*parents:slug} as well to accommodate tree-like models, and {link:slug} or {*links:slug} (where link is the name of the link field within this model that references e.g. categories) for when URLs are built up from fields across multiple models.

[lunelson]

Nice idea @Convincible! Yes what I called previewURL above could be thought of as instanceURL or instanceRoute: simply, the URL pattern at which the model will output in the application; which opens up quite a range of possibilities

[stefanoverna]

We will probably implement it using webhooks: you need to provide an endpoint that given a record ID will return the preview url for a specific record.

Any thoughts?

Il ven 27 lug 2018, 11:12 Lu Nelson notifications@github.com ha scritto:

Nice idea @Convincible https://github.com/Convincible! Yes what I called previewURL above could be thought of as instanceURL or instanceRoute: simply, the URL pattern at which the model will output in the application; which opens up quite a range of possibilities

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/datocms/feature-requests/issues/66#issuecomment-408360951, or mute the thread https://github.com/notifications/unsubscribe-auth/AADJdXEmGINKgPuP4j80G29o7fsO1GEBks5uKtljgaJpZM4VRZrt .

[lunelson]

OK so if I understand correctly you're talking about the original post use-case here... I supply an endpoint to a Model, which will parse the ID out of the query string (I guess?) and preview the record, yes?

And what do you think about the other ideas above, @stefanoverna ?

[lunelson]

Wait no I think I've misunderstood how this would work: you're saying that rather than provide the config options we described above as part of DatoCMS, you have DatoCMS ping my app with an ID and my app returns the URL for the preview... so the routing logic that determines what that URL is totally flexible. It's an elegant idea—it seems to me it could also be applied to the idea put forth by @Convincible above: i.e. it needn't be just for previews. What do you think of allowing both: instanceURL and previewURL. They could both be generated from the same endpoint. This might open the door for the ideas above, at a later point

[Convincible]

Two important points:

1. Dato generates the ids, not the endpoint.
2. URLs may depend on tree-like structures, fields within the model, and link fields between records.

Given these, how will the endpoint be able to know what is the correct URL for any given id, just from the id?

This would be simpler if, rather than sending the id to the endpoint, the record itself is sent, including any linked records (via parentage or link fields). But why send all this information around, just for the endpoint to pick out some fields and concatenate them?

The other downside to delegating to an external endpoint is that now I have to build, pay for and maintain a dynamic system that has to be responsive all the time. I love Dato because it is the only dynamic part of the stack, and it's all managed for me. Once stuff leaves Dato it's all static files.

[lunelson]

I think if we're meant to implement a single endpoint in our apps for all previews, you might need to post more to that endpoint than just the ID. The workflow described here by Rooftop CMS is close to what you are proposing @stefanoverna ;

however, it seems to me that if it was a matter of specifying a routing pattern, as I described in my first post, an ID would be enough, as presumably based on the route my app already knows whatever else it needs to know about the record with that ID.

One point from that Rooftop document I found interesting: it sounds like they also post a request key to the endpoint, which presumably allows the app to load exactly the specific draft/revision that the user is looking at...

[stefanoverna]

@Convincible I see your point. This endpoint could be a free AWS lambda function, so it not a matter of costs, really.. but you would have to maintain it, for sure.

An alternative approach could be that we ask developers to write custom JS script to express the routing logic and save it in the DatoCMS settings. We would then execute the code in a JS sandboxed environment. This would require much less maintenance on developers side.

[stefanoverna]

Pros:

• Zero maintenance costs from a developer's point of view

Cons:

• Developer is forced to use JS as language and learn something new instead of relying on known technologies/libraries/stack
• Could be more difficult to test/debug
• We would probably disable external modules and provide a fixed set of basic functions to use
• Routing logic stored in DatoCMS and not ie. on the project repo

[Convincible]

I see your point as well @stefanoverna. Is there not a good middle ground where some standard syntax or UI is used to specify the routing logic? This would seem to me to capture 99% of use cases in a simple way, while perhaps you could then allow lambdas as an option if it's insufficient in some case.

In nearly all cases, the routing logic is going to be some concatenation of slug fields. In fact, this feature would allow the slug field to show the actual URL of the page, rather than "example.com", automatically (replacing current 'URL prefix' Presentation option) – two wins!

"Some standard syntax or UI" could be a number of things. There are a number of familiar syntaxes that could be used, e.g. Jekyll, Ruby, JS, but none of them is complex.

For example:

• On the model settings, there is a routing setting, where you can add a route for each environment for that model
• The route is defined as a string containing variables that are to be interpolated, which refer to either:
  • fields in this model, e.g.
    • services/{type}/{slug}
    • #!page={slug}
  • fields in a model referenced via a link field in this model, e.g.
    • {category.slug}/{slug}
  • fields in this model, for this record and all its parents (in tree-like models), e.g.
    • faqs/{*slug}
    • categories/{*category.slug}/{slug}
• This gives the record's URI relative to the environment's root. The absolute URI is e.g. example.com/route
• More work, but this entire thing could be made into an interface for a 'route builder', i.e. requiring no particular code of any kind.

[stefanoverna]

Let's put in the table the possibility that for a specific record there is more than a preview URL (ie. multi-lingual websites)

[stefanoverna]

The thing is that I'm not a big fan of creating yet another pseudo-language to learn that will cover some cases.. :/

[Convincible]

For multi-lingual websites, the route would just take the value appropriate to the selected language. So, for a route {category}/{slug}, you would get e.g. "animals/horse" in en and "animaux/cheval" in fr if and only if those values were defined under the fr locale for that field in that model.

[Convincible]

I agree, I'm not keen to be honest on having a pseudo-language. I'd prefer it was an interface, where you drag blocks representing the fields of the models. I recognise that's a lot more work to implement.

Slightly better than a pseudo-language would be some standard syntax used more widely for defining URL patterns. I'm not sure I know any, though!

Better again would be a real language. What about allowing us to write the routing logic in either JS or Ruby – just like all your other APIs are offered in both JS and Ruby?

[stefanoverna]

A plugin has been recently published for that: https://www.datocms.com/plugins/i/datocms-plugin-preview-link/