-
Notifications
You must be signed in to change notification settings - Fork 51
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
localeFallbacks not working in latest versions. #196
Comments
We hit this problem too. We're interested in contributing a PR if maintainers can point us in the right direction. @stefanoverna @matjack1 |
I think this comes down to these lines https://github.com/datocms/gatsby-source-datocms/blob/master/src/hooks/sourceNodes/createNodeFromEntity/item/index.js#L22-L26 from 76520c4 @robertp-harrys For us this change is indeed correct. It is meant to create less nodes (faster Gastby sourcing) and more properly reflect the data models defined in Dato. In our case we had a singleton model which did not have any localised fields enable. As you show with version of this plugin before 76520c4 it created Gatsby Nodes for all locales defined in Dato regardless of whether or not the model defined any localised fields. After 76520c4 it now does the correct thing, no localised fields in the model? Then no Gatsby Node for those locales, resulting in fewer nodes and better performance. In our case our code relied on these "extra nodes" which was incorrect, we should rely on this data from other sources. Your case looks like something similar to ours. From my understanding of the code in this plugin you should not expect the plugin to create Gatsby Nodes for all your locales that are a copy of your fallback locales, but rather that the locales that do not have the translations get the VALUES from the first available fallback locale. So if you query for the Maybe some of this reasoning might help you understand your underlying issue. At this moment I think it is a data issue or configuration issue on your end or some misunderstanding of how the localisation feature works at Dato. It would be nice if any official dato member could confirm my findings above. |
That is correct @michaellopez. We're currently talking with Gatsby to see if we can do any better than this. Ideally, we'd like to replicate the way localization works with our GraphQL API. This would allow us to generate only one Gatsby node per record, and let the developer customize the locale (and fallback locales) to be returned on a per-field level... but some pieces are missing in the Gatsby API atm. I'll keep you posted! |
@michaellopez @stefanoverna Thank you for your input, however the explanation for how it should work is the same as our assumption today - and it makes total sense to only create nodes when the model has localisable fields. However, we have a model with a localisable field (called "count"), but the fallback content only returns if we actually add the locale to the record via the CMS - so given the locale mapping @robertp-harrys gave above; if we just want the For example with the following setup in the CMS (note the count is localisable, and I haven't added the 'fr-FR' locale so the expected final fallback is 3): and this fallback config:
Running this gql code from graphiql:
with I'm not sure if that makes sense so please let me know if not. If the solution is that we have to add every locale to any records then it seems like fallbacks are a little redundant and could result in a poor content editor experience / with lots of duplication. |
@jpriceharrys If you debug the lines I linked above the logic says the following:
If my understanding is correct, given your more detailed post above, I now consider this a bug with The If so should the logic change to include |
Yes, it is a bug. Happy to review a MR on this, thanks!
—
Stefano Verna
Founder and CEO @ DatoCMS
…--- original message ---
On June 8, 2022 at 4:01 PM GMT+2 ***@***.*** wrote:
@jpriceharrys If you debug the lines I linked above the logic says the following:
If there is no localised field, use the first locale defined in Dato
If there IS a localised field, check if the model requires all locales to have a value
If all locales are required
Generate a node for all locales because the source plugin can expect data to be defined for all locales
If all locales are NOT required
Check the entity for all locales that have a value and generate a node for each of those (I haven't debugged this with data, but this is what I think happens for the line Object.keys(entity[camelize(firstLocalizedField.apiKey)]);, @jpriceharrys please verify if you can)
If my understanding is correct, given your more detailed post above, I now consider this a bug with gatsby-source-datocms. Because just as you say, you are required to fill in a value for a locale for a Gatsby Node to be created for that locale.
The localeFallbacks option will only get processed for locales that have a value, which kind of defeats the purpose. @stefanoverna do you agree?
If so should the logic change to include localeFallbacks in the decision for localesToGenerate? I think that all locales that have a fallback defined in localeFallbacks should get a Gatsby Node generated with the fallback value. I can probably get a PR drafted if this is something the maintainers are willing to merge.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
--- end of original message ---
|
Alright, we just shipped v5.0.0-0, which:
You can read all the details here: https://github.com/datocms/gatsby-source-datocms/tree/experiment#localized-fields It would really help if you could provide a feedback! 🥳 |
Hey @michaellopez @jpriceharrys any news? :) |
Apologies @stefanoverna, this slipped off my radar. I will test it now and see how it goes, thank you! |
@stefanoverna just to check that I am getting this right - I have updated to version 5, but do we now need to change all queries we make to Dato to include the So for example the above query has to change to:
Note: I did realise that after I add the |
Hi @stefanoverna, I assume your release of I'll leave testing v5 for the outlined issues to @jpriceharrys and his colleagues. |
@jpriceharrys that is correct. Is this new strategy solving your previous querying issues? Are you able to retrieve everything you need now? |
Hi @stefanoverna. This looks like the fallbacks are working, however i'm not sure it's a path we would be able to move forward with due to now being a lot more cumbersome having to add the fallback locales to every query (we currently have ~60 queries throughout our codebase) plus we will have to make it so that our fallbacks are changeable based on the original requested locale (because the fallback for However, my biggest concern is when it comes to adding new languages and adding more fallbacks. In the past it was very simple as we just had to update the Is there any way to keep the setup as before in the gatsby-config? I don't mind having to change our queries structure from This might not be related to your code change (so please let me know if not - just wanted to highlight) when running the following query:
My development server crashes with the follow error (removing the
|
@jpriceharrys thanks for the feedback! First of all, regarding the error: would you be able to share your Gatsby project, so that I can take a better look at it? I'm not sure we can return to the settings in |
Hi @stefanoverna. I'll try to get a small POC with the |
@stefanoverna Please find a very simple dummy app here to show the issue. The steps to reproduce are in the README but if there is anything else, please let me know. We're using a test dato instance API read-only key which you can use too so you can see the structure of the model. |
Submitted to Gatsby team.. really appreciated @jpriceharrys... hope they can help us understand the cause :/ |
For the crashing part - we found culprit in gatsby using your repro (thank you!) - you can check gatsbyjs/gatsby#36552 to follow fixes being made to gatsby. With that I was at least able to execute query described in README: |
awesome! |
Above fix was just published in |
The new v5 is out! Closing this one! |
It appears that localeFallbacks don't work as expected in newer versions of gatsby-source-datocms
our defined localeFallbacks
Below Im posting 3 examples of data being returned differently for different versions of those plugins. The query is the same across all 3 examples.
Example 1 (Working as expected):
gatsby-source-datocms@3.0.15
datocms-client@3.5.9
Screenshot from
/___graphql
:Example 2 (Not Working):
gatsby-source-datocms@4.0.4
datocms-client@3.5.9
Screenshot from
/___graphql
:Example 3 (latest versions - Not Working)
gatsby-source-datocms@4.0.4
datocms-client@3.5.21
Screenshot from
/___graphql
:The text was updated successfully, but these errors were encountered: