-
Notifications
You must be signed in to change notification settings - Fork 1
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
feat: Add lang
option to DataType read operations
#473
Conversation
@EvanHahn non-urgent, but it would be great to have your eyes on this this week to check this approach makes sense. A full review can maybe wait until we get the dependencies in place, but the approach here might affect how we design the translation API. |
* start writing unit tests * error handling for missing translation * fix error in sql query
* fix logic error when `put` * handle unexisting key in the indexing (by creating a new Set) * make `fieldRef` and `regionCode` optional when `get`
* expose cache map through symbol and getter * improve `get` signature (by making `fieldRef` and `regionCode` optional) * add more unit tests
* add translationDoc to entries for batching indexer * move decoding of translationDoc into `.index` function in translationApi
…ranslationApi Also, have a fallback when no matching `regionCode` (can be reverted is it not desired)
TranslationApi need let translationApi;
const dataType = new DataType({
dataStore,
table,
db,
translation: translationApi
})
translationApi = new TranslationApi({
dataType,
table
}) This kinda feels weird but it seems to work. Could there be edge cases where this wouldn't work? Is there a pattern that we could have were we avoid this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add an e2e test too?
* Have better typing on `getByDocId` result * Avoid extra translation lookup * remove ts-ignore Co-authored-by: Evan Hahn <me@evanhahn.com>
…ecord-translations-opts-lang
`DataType` needs access to `TranslationApi.prototype.get`, but `TranslationApi` needs access to `DataType`. To avoid this circular reference, pass a `getTranslations` function into `DataType`.
…em/mapeo-core-next into feat/record-translations-opts-lang
@EvanHahn do you feel there are e2e-tests that we can add? The ones I added are pretty similar to the translationApi tests with the added layer of going through |
Nah, I think those are good enough! I'll review the rest now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Feel free to merge when CI passes.
Thanks for all the back-and-forth here.
Fixes #472
Depends on:
TODO:
The implementation in this draft PR tries to minimize the overhead for looking up translations.
Ready for an initial review.