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

i18n support #11

Closed
fabienheureux opened this issue Mar 19, 2019 · 3 comments
Closed

i18n support #11

fabienheureux opened this issue Mar 19, 2019 · 3 comments

Comments

@fabienheureux
Copy link

fabienheureux commented Mar 19, 2019

Hey, I went through the docs and am not sure about how it handles language in request.
Does the cache invalidate if language in the request changes?

I have a nextjs app running with i18next and ssr got pretty buggy when I try to use cacheable-response.

Thanks a lot for tour work by the way, docs are very well written and the package itself is very easy to use.

@Kikobeats
Copy link
Owner

Hey fabie! thanks for your words 🙂

I'm not using multilanguage in my user case, so I didn't implement the library for support that.

However, we can add it. How this is normally done?

I suppose the client needs to send a request header with the i18n, then the server tries to find or cache a specific translation response for that.

Can we find any reference that defines how this can be implemented?

@Kikobeats Kikobeats changed the title Invalidate cached based on locale c i18n support Mar 19, 2019
@dimensi
Copy link

dimensi commented Apr 3, 2019

The package uses req.url as the key, and nextjs to determine which page to generate by default req.url.
For example, there is a package for next.js next-i18next, where it cuts out the req.url subpath in which the language is enclosed. Thanks to this trick, nextjs knows which page to generate, and the browser client gets a url with the language. Without having to specify the page directly in nextjs.

I solved this problem by giving your package a path with the language, and nextjs without the language.

const ssrCache = cacheableResponse({
  ttl: hoursToMs(6),
  get: async ({ req, res, pagePath, queryParams }) => ({
    data: await app.renderToHTML(req, res, pagePath, queryParams),
  }),
  send: ({ data, res }) => res.send(data),
})

  server.get('*', (req, res) => {
    if (req.url.includes('_next/') || req.url.includes('static/')) {
      return handle(req, res)
    }

    const pagePath = req.url // '/pages'
    req.url = req.originalUrl // '/en/pages'
    return ssrCache({ req, res, pagePath })
  })

I suggest that in order to avoid such problems in the future, it is possible to add the key directly, if the key is not added then use req.url

ssrCache({ req, res, key, pagePath })

Looking at the design of your package, I see that we cannot generate the key inside the get() function. That's why I see only this solution.

@Kikobeats
Copy link
Owner

@dimensi @fabienheureux can you take a look to #22? I think it's strongly related since both things are trying to do the same: differentiate cache storage instances using more things that the query parameters passed.

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

No branches or pull requests

3 participants