feature request: use route info from url

[KiaraGrouwstra]

For a URL /products/123, can we grab and use that 123 from the URL to fetch and display the corresponding data?

Potential advantages:

• reuse the template, handling user clicks on related products with a setState.
• a single static asset could be used across the different items. I'm hoping this would facilitate combining AMP with a serverless architecture.
• skip another page load when navigating to a different item.
• keep logic dynamic to reuse in the PWA, where I fear hard navigation would result in loss of application state (AMP.setState stuff).

(earlier posted on SO, here reworded as a feature request as afaik it seems to be missing.)

[aghassemi]

@tycho01 AMPDOC_HOSTNAME in variable substitution will have this information. A parsing function to give you exactly the segment you want is missing ( maybe URLPATH_SEGMENT(index) ) but you can work around that.

[aghassemi]

/to @jridgewell

[jridgewell]

We have SOURCE_URL and SOURCE_PATH already. We might be able to add a function that grabs a segment of the pathname, something like a slice of how many slash parts to include:

SOURCE_PATH_SEGMENTS(start_slash, length)

// SOURCE_PATH_SEGMENTS
const segments = SOURCE_PATH.split('/');
return segments.slice(start_slash + 1, length).join('/');


SOURCE_PATH_SEGMENTS(0) // => 'products/123'
SOURCE_PATH_SEGMENTS(0, 2) // => 'products/123'
SOURCE_PATH_SEGMENTS(0, 1) // => 'products'
SOURCE_PATH_SEGMENTS(1, 1) // => '123'

[KiaraGrouwstra]

Thanks! These are looking pretty good already.
To my understanding, as per the SO thread, these can be used in e.g. amp-list's src.
To keep things dynamic, I suppose in practice it would be nice to store this as part of the state, so that 'related products' links could swap out the data.
In my current understanding, amp-state would not presently support variables/operations though, as it is using JSON format. I imagine that could maybe be circumvented through some setState operation, though that sounds a bit hacky.

[jridgewell]

It's unlikely I'll be able to get to this any time soon. Would you like to make a Pull Request?

To my understanding, as per the SO thread, these can be used in e.g. amp-list's src.

I don't know how dynamic <amp-list>'s src attribute can be. Off the top of my head, I don't think it supports variable substitutions by default.

[KiaraGrouwstra]

The SOURCE_PATH_SEGMENTS looks doable, yeah. Heck, it's short enough this variable substitution looks great even without this extra step in abstraction.
On usage, would there be a way to use this variable substitution to specify an initial state? Or am I thinking about things the wrong way there?

[jridgewell]

/cc @choumx. I'm out of my element with AMP's state mechanisms.

[KiaraGrouwstra]

Angular/React routers use say products/:id to capture params; may be useful here too?

[KiaraGrouwstra]

Related question on dynamic vs. static AMP w.r.t. SEO: does info dynamically loaded in by amp-list's src get read by Google to consider as searchable content?

[dreamofabear]

Having <amp-state>'s JSON state initialized with URL path data sounds error prone since a single AMP page can have multiple URLs (CDN, origin, viewer, etc.). It doesn't sound like you need this for your use case.

<amp-state>'s src attribute does support URL variable substitutions: https://github.com/ampproject/amphtml/blob/master/spec/amp-var-substitutions.md#overview

[KiaraGrouwstra]

@choumx:

Having <amp-state>'s JSON state initialized with URL path data sounds error prone since a single AMP page can have multiple URLs (CDN, origin, viewer, etc.). It doesn't sound like you need this for your use case.

Yeah, it isn't strictly necessary. I was mostly wondering whether I would need a back-end language, or if AMP could handle it and having the back serve static assets would suffice.

It's admittedly a trade-off, where the complexity would have to be handled on either one side or the other.

Static assets offer some advantages (easier caching rules, can be served from any kind of server), while it seemed the AMP side might also benefit from keeping things reusable, so I figured it was worth asking.

[ampprojectbot]

This issue doesn't have a category which makes it harder for us to keep track of it. @jridgewell Please add an appropriate category.