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

Pass function in plugin options to gatsby-browser.js #3834

Closed
HriBB opened this issue Feb 3, 2018 · 4 comments
Closed

Pass function in plugin options to gatsby-browser.js #3834

HriBB opened this issue Feb 3, 2018 · 4 comments

Comments

@HriBB
Copy link

HriBB commented Feb 3, 2018

How can we pass functions in plugin options?

app/gatsby-config.js

{
  resolve: `gatsby-plugin-i18next`,
  options: {
    getLanguage(pathname) {
      return pathname.substr(1,2) === 'en' ? 'en' : 'si'
    },
    config: {
      fallbackLng: 'en',
      ns: [],
      interpolation: {
        escapeValue: false, // code escaping in interpolated text is not needed with react
      },
      react: {
        wait: false,
      },
    },
  },
},

gatsby-plugin-i18next/gatsby-node.js

exports.onCreatePage = ({ page } , pluginOptions) => {
  console.log(pluginOptions);
}

Output of console.log

{ plugins: [],
  config: 
   { fallbackLng: 'si',
     ns: [],
     interpolation: { escapeValue: false },
     react: { wait: false } } }

As you can see, getLanguage function is not available in plugin options. Am I missing something obvious here?

@HriBB
Copy link
Author

HriBB commented Feb 3, 2018

Hmm wait, getLanguage IS available in gatsby-node.js, but not in gatsby-browser.js

@HriBB HriBB changed the title Pass functions to plugin options Pass functions to plugin options in gatsby-browser.js Feb 3, 2018
@HriBB HriBB changed the title Pass functions to plugin options in gatsby-browser.js Pass function to plugin options in gatsby-browser.js Feb 3, 2018
@HriBB HriBB changed the title Pass function to plugin options in gatsby-browser.js Pass function in plugin options to gatsby-browser.js Feb 3, 2018
@calcsam
Copy link
Contributor

calcsam commented Feb 4, 2018

What are you trying to do exactly?

Gatsby has a build step where pages are generated, where the code from gatsby-node are called. It also runs some code client-side, where the code from gatsby-browser is called. getLanguage deals with client navigation and path, why are you running it in gatsby-node?

@HriBB
Copy link
Author

HriBB commented Feb 5, 2018

I was trying to write a i18n plugin, where user would define a function in the plugin config. This function would be used throughout the plugin code, to determine the language from pathname. I tried to do something like this in gatsby-browser.js:

exports.onClientEntry = (obj, { getLanguage }) => {
  //const language = getLanguage(window.location.pathname) // getLanguage is undefined
  const language = window.location.pathname.substr(1,2) === 'en' ? 'en' : 'si'
  i18next.changeLanguage(language)
  }
}

exports.onRouteUpdate = ({ location }, { getLanguage }) => {
  const language = location.pathname.substr(1,2) === 'en' ? 'en' : 'si'
  if (i18next.language !== language) {
    i18next.changeLanguage(language)
  }
}

But it's not possible, because pluginOptions in gatsby-browser.js is JSON.stringified version of the config options and does not contain functions. Might be worth mentioning in the docs. You can close this issue I guess ...

After some thought, I used a different approach. By creating a custom graphql Locale node, I am able to query translations and dynamically load language and/or namespace using a HOC. I will try to extract it into a plugin, might be useful for someone else.

@m-allanson
Copy link
Contributor

@HriBB Thanks for the update, there's now a note in the docs about plugin config stringification.

CanRau added a commit that referenced this issue Apr 18, 2019
I'm not entirely sure about this, I'm aware of the origin #3987 yet this PR I made proofs the opposite #12060 
Only thing I can think of right now that browser APIs get stringified, couldn't verify this so far, this #3834 is suggesting they get stringified and it's the reason the note was added to the docs in the first place..

Couldn't just leave my confusion alone and thought doing it in a PR might be useful if it's actually not valid anymore so it can be merged directly, otherwise feel free to reject it of course 👍
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