-
Notifications
You must be signed in to change notification settings - Fork 166
Rich Text Versioning optimizations [MAPS-137] #10334
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
base: master
Are you sure you want to change the base?
Conversation
FBanfi
left a comment
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! 💯 🚀
| }); | ||
| return fetchedAssets.items; | ||
| } catch (error) { | ||
| console.error('Error fetching assets:', error); |
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.
💭 should we notify users? So they know that something went wrong. Also in the getEntries and the content type fetch?
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.
We're already doing that 😎 In the createOptions function if we can't identify the entry, asset or content type we just display it as unknown. This just logs the specific error in the console to be able to debug
JuliRossi
left a comment
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.
Looks good! Left some questions
| name: 'Fruits', | ||
| sys: { id: 'fruits' }, | ||
| fields: [{ id: 'title', name: 'Title', type: 'Symbol' }], | ||
| mockSdk.cma.contentType.getMany = vi.fn().mockResolvedValue({ |
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.
Consider adding a test to trigger the response too big error and see if the app handles it appropriately. Although this PR optimizes to avoid this situation with the updated querying it might also be worth thinking about how it might fail even with these optimizations
ryunsong-contentful
left a comment
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.
Certainly an improvement and probably would fix the customer issue, but it's still possible to get a response too big error. So probably worth adding a test to see what happens when it still gets that error and maybe come up with a creative solution around the worst case still.
Purpose
A customer is having an issue in which the dialog of the app is not displaying correctly due to a "response too big" error.
Approach
We've introduced some optimizations so requests made by the app have a smaller response size:
createOptionsmethodselectparamester to only retrieve the title, which is the only thing that gets usedinclude: 0parameter when usingentry.getPublishedsince by default the response includes anincludearray that is not used