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.

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

Ability to specify cutsom keys (or paths) #37

Open
DelfsEngineering opened this issue May 30, 2018 · 3 comments
Open

Ability to specify cutsom keys (or paths) #37

DelfsEngineering opened this issue May 30, 2018 · 3 comments

Comments

@DelfsEngineering
Copy link

DelfsEngineering commented May 30, 2018

I have a use case where my app responds to multiple domains.

As such the cache returns the same data for /somepath/someId for each of the domains. Is there a way to specify custom keys so I can add my own key in? perhaps in some before hook?

@idealley
Copy link
Owner

idealley commented Jun 2, 2018

Is this different from your previous question (#35 )?

The main idea for me was to use the path of the api request as a "group" and the "slug" or the last segment of the request as the item key.

We could image a configuration option that would allow to use the full path as key. Let say now I have an api living at api.domain.com and an endpoint news that can also take an article slug news/:slug to return a single article.

This setting would generate a group key group-news a parent key news and an item key news for a single article an item only the key would be different something like the-slug-of-my-article. The domain is ignored all together.

Therefore we could imagine an option includeDomain: true that would generate a group key like group-domain.com-news like this you would know which domain saved the item in the cache and it would not break backward compatibility.

What do you think?

@DelfsEngineering
Copy link
Author

Thanks for the reply, Yes that would work, Although I would think the domain inclusion is not common, but the ability to add data that would be part of the key would be valuable.

It would seem that a switch something like useCustomKey: true would also maintain compatibility also. I would think you would add the custom key in via an earlier hook. This would give any dev 100% control of groups and keys then ... ?

@idealley
Copy link
Owner

idealley commented Jun 5, 2018

That makes sense. I agree the custom key would be a nice addition.

Would you have time to do a pull request? With an example of the earlier hook?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants