@bearND I was thinking the interface for this could take two callbacks: wmf.fetchAndAppendRelatedPages(isSavedHandler, saveButtonHandler)

isSavedHandler would be a function that takes a string with an article URL

(articleURL) => { ...native message handling here... }

When receiving the isSavedHandler callback, the app would figure out whether or not that article has been saved by the user, and call:

wmf.setArticleIsSaved(articleURL, isSaved)

saveButtonHandler would be a function that takes a string with an article URL and a boolean with whether or not the user intended to save or unsave the article

(articleURL, isSaved) => { ...native message handling here... }

When receiving the saveButtonHandler callback, the app would save or unsave the article and then call:

wmf.setArticleIsSaved(articleURL, isSaved)

with the correct save state after the action is completed.

In practice on iOS this would look like

wmf.fetchAndAppendRelatedPages((articleURL) => {
    window.webkit.messageHandlers.isSavedHandler.postMessage({"articleURL": articleURL})
},
(articleURL, isSaved) => {
    window.webkit.messageHandlers.savedButtonHandler.postMessage({"articleURL": articleURL, "isSaved": isSaved})
})

Open to other suggestions if this wouldn't work on the JS side or if there's a cleaner way to do it.

@JoeWalsh I think this should work. Thank you!

Pending discussion with the team, the save button handler part of this could be taken care of by T219998 depending on if it makes more sense to have a single interaction handler or multiple interaction handlers

In T217352#5081849, @JoeWalsh wrote:

Pending discussion with the team, the save button handler part of this could be taken care of by T219998 depending on if it makes more sense to have a single interaction handler or multiple interaction handlers

@JoeWalsh is the discussion still pending? Should we discuss at App engineering sync? If not, is there anything to add to the task?

Thanks.

@MSantos this was discussed and the interaction handling portion should be part of the shared interaction handler defined in T219998. I will update the description to reflect this.

Yes, the saved state could be handled as part of the interaction handling, in a follow up to T219998.

The main part for this task could be done independently from the interaction handling work: We still need to get the list of related pages. To do that it'll make a separate network request. That fetch could be done either shortly after the DOM is loaded or lazily when the user scrolls down close to that area.

@bearND I was thinking the fetch should happen when the clients call a method like pagelib.c1.PageMods.fetchAndAppendRelatedPages(). That way there wouldn't need to be a determination when to append the related pages, the clients could decide if and when they wanted to fetch them.

@MSantos @bearND I updated the task description with a clearer definition of the request. Let me know if you have any questions

@JoeWalsh Thank you for updating the description. One part is not clear to me yet. Maybe I have missed it.
Where are the readMore items coming from? Is the app providing this list or is the JS layer expected to query that?

Update: Ah, I see pagelib.c1.PageMods.fetchAndAppendRelatedPages() in your previous comment. So, the apps call pagelib.c1.PageMods.fetchAndAppendRelatedPages(domain, title), which then in turn fetches the read more titles. But then it would also have to call back to the app to get the saved state for each read more article.

@bearND JS layer would query for that - it looks like that's already in pagelib

@JoeWalsh Ok, thanks!

For whoever picks this up - I did a rough initial implementation here: https://github.com/wikimedia/wikimedia-page-library/pull/208 feel free to take over that branch and run with it or close the PR if it's not useful

Mentioned in SAL (#wikimedia-operations) [2019-07-02T17:43:34Z] <bsitzmann@deploy1001> Started deploy [mobileapps/deploy@9ca9b0f]: Update mobileapps to 941e14f (T219998 T217352 T219909)

Mentioned in SAL (#wikimedia-operations) [2019-07-02T17:49:24Z] <bsitzmann@deploy1001> Finished deploy [mobileapps/deploy@9ca9b0f]: Update mobileapps to 941e14f (T219998 T217352 T219909) (duration: 05m 49s)