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

fix: Dashboard parsing error #360

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 0 additions & 16 deletions Core/Core/Data/Model/Data_Dashboard.swift
Original file line number Diff line number Diff line change
Expand Up @@ -102,7 +102,6 @@ public extension DataLayer {
public let number: String
public let org: String
public let start: String?
public let startDisplay: String
public let startType: StartType
public let end: String?
public let dynamicUpgradeDeadline: String?
Expand All @@ -112,9 +111,6 @@ public extension DataLayer {
public let courseImage: String
public let courseAbout: String
public let courseSharingUtmParameters: CourseSharingUtmParameters
public let courseUpdates: String
public let courseHandouts: String
public let discussionURL: String
Comment on lines -115 to -117
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 💸 🚀

public let videoOutline: String?
public let isSelfPaced: Bool

Expand All @@ -124,7 +120,6 @@ public extension DataLayer {
case number
case org
case start
case startDisplay = "start_display"
case startType = "start_type"
case end
case dynamicUpgradeDeadline = "dynamic_upgrade_deadline"
Expand All @@ -134,9 +129,6 @@ public extension DataLayer {
case courseImage = "course_image"
case courseAbout = "course_about"
case courseSharingUtmParameters = "course_sharing_utm_parameters"
case courseUpdates = "course_updates"
case courseHandouts = "course_handouts"
case discussionURL = "discussion_url"
Comment on lines -138 to -139
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

case videoOutline = "video_outline"
case isSelfPaced = "is_self_paced"
}
Expand All @@ -147,7 +139,6 @@ public extension DataLayer {
number: String,
org: String,
start: String?,
startDisplay: String,
startType: StartType,
end: String?,
dynamicUpgradeDeadline: String?,
Expand All @@ -157,9 +148,6 @@ public extension DataLayer {
courseImage: String,
courseAbout: String,
courseSharingUtmParameters: CourseSharingUtmParameters,
courseUpdates: String,
courseHandouts: String,
discussionURL: String,
videoOutline: String?,
isSelfPaced: Bool
) {
Expand All @@ -168,7 +156,6 @@ public extension DataLayer {
self.number = number
self.org = org
self.start = start
self.startDisplay = startDisplay
self.startType = startType
self.end = end
self.dynamicUpgradeDeadline = dynamicUpgradeDeadline
Expand All @@ -178,9 +165,6 @@ public extension DataLayer {
self.courseImage = courseImage
self.courseAbout = courseAbout
self.courseSharingUtmParameters = courseSharingUtmParameters
self.courseUpdates = courseUpdates
self.courseHandouts = courseHandouts
self.discussionURL = discussionURL
self.videoOutline = videoOutline
self.isSelfPaced = isSelfPaced
}
Expand Down
Loading