Plugin design suggestion: full page or modal?

Dev
1

Hi everyone :slight_smile:

I am writing a plugin for Keybase Proofs, and since it is my first attempt at writing a Discourse plugin, I am still trying to figure out the best way to integrate it with the product :slight_smile:

The plugin itself needs just a couple UI components, and one of them is still a bit tricky for me to implement: the page that shows the association between the Discourse user and the Keybase user (see the screenshot here).

The easiest way for me to implement it is a full page, for example served at /keybase-proofs/new-proof, but it seems like it is discouraged to have a plugin define their own full pages (@eviltrout I think I remember you writing about this somewhere, perhaps you can give me some hints?).

So what I am trying to do instead is having a modal dialog appear when the url to create the association is hit. So ideally I’d like to show the Discourse homepage with a modal on top, using an outlet. Would this be a better design? If so: how do I make the modal appear only when a specific url is hit, with the homepage in the background? The only way I see to make this happen is to use query parameters:

https://${MY_DISCOURSE_SITE}/?new_keybase_proof=true&kb_username=...

Here, I would use new_keybase_proof=true to decide if I need to show the modal or not.

UPDATE: Perhaps I should do something like what happens for /login? That is, do a redirect to the homepage in the route beforeModel() method and then call the method that shows the modal?

3 Likes
2

With a lot of the mobile stuff we were stuck doing full page cause the technique we used involving post message in JS ended up failing.

Can you elaborate a bit about the process after you click associate? Does it redirect to key base and then redirect back to us?

If there is a redirect chain involved you are going to need a new route here with a new full page. If this is simply making a call to the discourse server and it takes care of the magic, then you can get away with a modal.

3 Likes
3

After you click associate, it just redirects to a Keybase url which then redirects to the Keybase app/website as needed, it doesn’t get back to Discourse.

This is the skeleton of the plugin so far (I’ve only committed the files related with the new-proof page for now, plus a couple more files): GitHub - etamponi/discourse-keybase-proofs-plugin: Discourse Plugin for Keybase Proofs

As you can see, this is the flow:

  1. Keybase asks the user to go to https://$DISCOURSE_SITE/keybase-proofs/new-proof?kb_username=bla&username=blabla&...

  2. Discourse checks if a user is logged in. If not, it redirects to the login page, then back to the new-proof page

  3. Discourse shows the homepage with a modal on top which will show the association details and the associate/cancel buttons

I’ve still to code the rest of the flow, but I’d like to make sure that we agree on the design so far.

1 Like
4

This may be way off base, but could you instead of having a plugin just have the keybase user insert some string in their profile about_me? (https://meta.discourse.org/my/preferences/profile) Then no plugin would be required and people could have a proof on any Discourse site, not only those who had heard of KeyBase and were willing to install a non-standard plugin.

Edit: Oh, see Discourse Keybase Proof where this discussion seems to be happening.

5

Yep, I am the same person in both threads :slight_smile: In here, I was just trying to understand which of the two designs for the association page was better: modal, or full page. I am going for a modal now, but it should be easy to replace it with a full page if needed :+1:

2 Likes