Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Whitelist user-defined pathnames #26

Open
gauravkg15 opened this issue Mar 4, 2019 · 7 comments
Open

Whitelist user-defined pathnames #26

gauravkg15 opened this issue Mar 4, 2019 · 7 comments
Labels
documentation enhancement New feature or request

Comments

@gauravkg15
Copy link

Goal: Only allow prefetching links with certain (origin + pathname) defined by the user

Why: Adding the 'data-no-instant' attribute is hard to scale. Some endpoints can trigger actions without query params so its much easier just to define a static list of whitelisted pathnames.
@Lozula
Copy link

Lozula commented Mar 9, 2019

Would like to see this too - a predefined list of url's that prefetch would be user than adding attributes to specific links would be easier to implement

@atilacamurca
Copy link

@gauravkg15 is this the same as issue #18?

Here's an example of the PR #29 will look like:

<html>
  <body data-instant-whitelist-mode>
    <a href="#1" data-instant>Instant link</a>
    <a href="#2">Not an Instant link</a>
  </body>
</html>

@Lozula
Copy link

Lozula commented Mar 22, 2019

My interpretation (or preference anyway!) is that you could whitelist some domains, rather than having to add an attribute to every link you want prefetched. For example, I have two websites, and I would like links on either of them to be prefetchable by the other, by just adding their domains to a whitelist instead of having to add an attribute to every link.

@PikachuEXE
Copy link

But then how to you expect to define a set of destination URLs
within the HTML document?
Let me throw an ugly example of expectation
(Not saying it should be implemented like this, throw your own one)

<html>
  <body data-instant-whitelisted-url-regex="^(https://domain-1.com|https://domain-2.com/pokemons)">
    <a href="https://domain-1.com/" data-instant>Instant link</a>
    <a href="https://domain-2.com/pokemons/pikachu">Instant link</a>
    <a href="https://domain-2.com/regions">Not an Instant link</a>
    <a href="https://domain-3.com/pikapika">Not an Instant link</a>
  </body>
</html>

Or do you expect to use it in JS way?

@gauravkg15
Copy link
Author

@atilacamurca This isn't the same as that issue #18. The crux of the problem is that adding attributes to every anchor is hard to scale, especially on dynamically generated ones from templating engines. It would be very helpful to just whitelist certain pathnames that you know are for fetching data, and not for triggering some action on your backend.

A solid way of accomplishing this is to encapsulate the module in a class, and provide a constructor you can pass an array into. Would work the same, except you would just need to add one line to 'activate' the functionality. Kind of like footable, $('.table').footable(); but instead, InstantPage.init(args) with one arg being an array of whitelisted pathnames, with which the module checks against in isPreloadable

@dieulot
Copy link
Member

dieulot commented Aug 16, 2019

You can currently define a list of links to preload in a variable, then iterate over each link in your page and add a data-instant attribute to those that points to a destination in that list.

There’s not much of a need to make it a real option, so that’s not planned.

@dieulot dieulot closed this as completed Aug 16, 2019
@dieulot
Copy link
Member

dieulot commented Apr 9, 2023

I plan on adding something along the line of instantpage.init(args) in v6; this use case might be a good fit there.

@dieulot dieulot reopened this Apr 9, 2023
@dieulot dieulot added enhancement New feature or request documentation labels Apr 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
documentation enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@atilacamurca @PikachuEXE @dieulot @Lozula @gauravkg15