fix: Dashboard parsing error

[volodymyr-chekyrta]

Issue: #359

Solution Description:
Removed unused fields in the Data_Dashboard.swift to fix the parsing error.

[openedx-webhooks]

Thanks for the pull request, @volodymyr-chekyrta! Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

• supporting documentation
• Open edX discussion forum threads
• timeline information ("this must be merged by XX date", and why that is)
• partner information ("this is a course on edx.org")
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

Please let us know once your PR is ready for our review and all tests are green.

[saeedbashir]

@miankhalid in the production app, we are using course_handouts to show/add the Handouts in the course menu and likewise, we are using discussion_url to enable/disable course discussions and course_updates being used for course announcements. e.g if discussion_url is nil, discussion tab won't be added in the course menu on course dashboard screen.

Should we remove these or keep them and create a ticket to get parity with the production app?

[volodymyr-chekyrta]

It makes sense to add these fields to the course home API and use them from there, we can't rely on them from the dashboard response as we have many ways to get to the course page without a dashboard (course about, deeplink, etc.).

[miankhalid]

@volodymyr-chekyrta the only downside I'm seeing with this approach is we're fattening the response of the said API. Currently, there are courses on our side whose response for Blocks has reached size close to 2 to 3Mbs.

If we keep on adding stuff, it'll only increase further. Plus, Glib will have to update his PR openedx/edx-platform#34273 even further.

For now, I do think we can update this API but in the longer run we should look into splitting these responses into atleast 2 APIs where:

1. one would just return Blocks
2. and the other one would return all the course related details

thoughts?

[volodymyr-chekyrta]

Sure, sounds reasonable 💯 👍!
But I'd like to check out the size and speed difference before we make any decisions.

[miankhalid]

yep that's why I've asked if Glib can do some performance & load testing before and after the change in his PR.

[shafqat-muneer]

Consider this idea: If we render all fields optional, it would prevent any disruptions in functionality, even if certain fields remain unused or no data is received from the backend.

[volodymyr-chekyrta]

Certainly, however, since we currently have no use for these fields, there's no need to waste resources on them.

• Less code is less complexity for everyone 🧠
• Less dead code, less cost of code ownership 💸 🚀

[openedx-webhooks]

@volodymyr-chekyrta 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future.