Support for pinned requests #1471

develohpanda · 2019-04-27T06:58:25Z

Closes #1344. Closes #1109.

Following feature set is not as merged given changes from discussions in this PR.

Features

Only allows pinning of top level request and request-group
Prevent drag/drop of pinned items
- Dragging nested items into/out of a pinned request-group is possible
- Manipulation of nested items remains unchanged
Independent scrolling for pinned and unpinned items
- Pinned items always remain at the top
Pinned item list + separator shown when at least one pinned item exists
Pinned item list height constrained via fit-content(20%)
- Auto height up to 20%, after which scroll bar will show
- 20% will allow for 6 items to be pinned before overflow scrollbar shows
Pin/Unpin action items added to action drop-downs
fa-thumb-tack shown on pinned items

pinned state is stored in request-meta and request-group-meta

Screenshots

No pinned items (current behavior):

Pinned folder + request, with unpinned items:

Six pinned items:

Seven pinned items:

Open tag on collapsed, pinned folder to allow dnd of nested items:

Action dropdowns:

No pin action on nested items:

gschier · 2019-04-27T09:23:14Z

I did a once over of the code and it looks great. Nice work!

One high-level thing though is that I think people will want to be able to pin any request, not just the top-level ones. I'm not sure pinning folders is useful, although maybe you can point out some use-cases that I haven't considered.

Overall great work on this. I'm super excited to get this one merged 💯

packages/insomnia-app/app/ui/components/sidebar/sidebar-children.js

develohpanda · 2019-04-27T11:51:49Z

Thank you - I appreciate it! 😄

I'm not sure pinning folders is useful

I see pinned items as those being truly global, which would really only be authentication requests. If all requests are pinned, then none of them are pinned so I agree with your sentiment. 😄 Only example I can think of is with larger solutions with multiple APIs and 3rd party integrations where there may be logical groupings for pinned items.

Your call - given it is probably a niche use-case I could remove the ability to pin folders and add if a request comes up.

people will want to be able to pin any request, not just the top-level ones

Enabled the pin action item in nested items
Updated parentId to the active workspace id inside the pin handle method
I didn't update this behavior for request-groups given the discussion above. Will update accordingly depending on the outcome. :)

gschier · 2019-04-27T14:30:54Z

Yep that sounds good. Pinned requests for now and folders if people want those later.

Just a little background. The original use case for pins that I remember is basically treating them as tabs (like in a text editor). So you might pin just the few requests you're working with at the moment.

_{Sent with GitHawk}

develohpanda · 2019-04-27T16:17:10Z

Makes sense. Done deal, PR has been updated!

rickychandra · 2019-04-30T07:39:33Z

@develohpanda Hi, just a suggestion. Would it be better if the pin icon is at the left side? Putting it at the right side will take up the dropdown's arrow, and will be moved aside when the request row is hovered over, which IMHO is a bit awkward 😄.

develohpanda · 2019-04-30T08:26:53Z

Would it be better if the pin icon is at the left side?

Thanks for the suggestion @rickychandra! I have a few reasons why I decided against an icon on the left which I'll outline below, but my ears are open to anything I may have missed. 😄 (apologies in advance for the long message!)

Padding inconsistency. If I move it to the left had side, it shifts the folder icon/method tag + text to the right, but only for pinned items. This alignment is inconsistent with unpinned items, and reading at a glance becomes tricky (similar to reading a balance sheet where the decimal point is not aligned with every other line). This is a hindrance and will slow down navigation.
Unnecessary cluttering. Differentiating request from folder (ie. method tag vs folder icon), and one row from another (ie. name) is more important than differentiating a pinned row from an unpinned row. A pinned row will always be at the top regardless, so adding unnecessary cluttering to the first two items (tag/folder + name) only gives more for the user to ingest. This is also a hindrance that will slow down navigation.
Cost/benefit.
Pin on left
Cost: styling inconsistencies + unnecessary cluttering that are always visible
Benefit: no movement of pin when hovering over a row
Pin on right
Cost: movement of pin only on hover to make way for dropdown arrow
Benefit: styling consistency, no UI hindrances introduced for primary tasks (navigating to and identifying a row).

The pin is only supplementary info necessary for certain rows, and is kept out of the way. The drop-down arrow is similar, in that it is supplementary info only for hovered rows, and is kept out of the way (or hidden) when not needed.

rickychandra · 2019-04-30T10:43:14Z

The pin is only supplementary info necessary for certain rows

Ah I see. I thought the pin is also clickable, so it would be easier to click if it doesn't move on hovered.

I agree with point 1 and 2, putting the pin on the left can make it hard to skim the items, especially when the pinned status is no longer that important (all pinned items are at the top and are separated with a line with the rest of the items).

Good job anyway! 😄

develohpanda · 2019-04-30T10:46:12Z

Thank you! Appreciate the suggestion 🥂

gschier · 2019-04-30T17:36:15Z

After testing out your branch locally, I have a few usability questions/suggestions:

I expected pinning a request keep showing the request in its original position (I couldn't think any apps that support pinning besides GitHub but this is how GitHub issue pinning behaves there)
I expected the pin icon on the right to unpin the request. Having it move out of the way on hover felt jarring. I think it would either feel better if the pin icon disappeared on hover or that the dropdown caret appeared to the left of the pin icon instead of to the right. Also, if we decide to show both icons, clicking the pin icon should unpin it too.
It would be super useful to have a keyboard shortcut to toggle the pin state of a request. Let me know if you need help with this one.

And a bug: When pinning a request that's in a folder, then unpinning, the request is no longer inside the folder.

Let me know if your thoughts on these or if you have any questions 😸

gschier

Really nice work on this. Just a few fairly minor comments 👍

packages/insomnia-app/app/ui/components/dropdowns/request-actions-dropdown.js

packages/insomnia-app/app/ui/components/sidebar/sidebar-request-row.js

packages/insomnia-app/app/ui/containers/app.js

packages/insomnia-app/app/ui/css/components/sidebar.less

develohpanda · 2019-04-30T19:51:34Z

I expected pinning a request keep showing the request in its original position

Do you mean for the pinned request to show in two places - nested section and its original position? 👍

I think I won't be able to get to these until the weekend. Thank you for the feedback!

gschier · 2019-05-01T02:00:59Z

@develohpanda yes, show in both places 😄

Don't worry, take your time!

…lace

develohpanda · 2019-05-04T04:35:25Z

@gschier two questions:

How should the filter behave with pinned requests? IMO pinned items should not be affected by filters and should always be visible.
Given pinned items are to show in both places, should the pin icon also show in both places (or only in the pinned list at the top)?

When showing items in the pinned list at the moment, it is referencing the same object (as I am not creating a new one). Thus selecting, renaming a row in the pinned list does the same to the request in its original location (and vice-versa). (You can observe this when testing). Therefore I am inclined to to show the pin icon in both places too.

develohpanda

@gschier I have updated the PR with your feedback and added a few comments. Let me know what you think!

develohpanda · 2019-05-04T07:25:19Z

packages/insomnia-app/app/ui/components/sidebar/sidebar-children.js

+  pinned: Array<Child>,
+  all: Array<Child>,
+};
+


Is there a more appropriate place to put this type definition?

I'm okay with it here. It makes sense to have it defined where it's used.

develohpanda · 2019-05-04T07:27:32Z

packages/insomnia-app/app/ui/containers/app.js

+            this.props.activeRequest,
+            !(metas[0] && metas[0].pinned),
+          );
+        },


Not a big fan of this solution, but the other solution would be to put the pinned on Request rather than RequestMeta, but more changes will need to go into app.js to support it. 🤔

Are there any other options that I am missing?

Just thinking, whatever solution is decided here could also be used to show a pin icon/reordering for pinned requests in the quick switcher.

We'll need to keep pinned on RequestMeta. The "meta" models are meant to store information that isn't related to actually sending the request and also that should not be synced or shared.

Note. One thing that would help here is using the getOrCreateByParentId method on request-meta.js.

Also, you'll need to add a check to make sure activeRequest is not null

Note. One thing that would help here is using the getOrCreateByParentId method on request-meta.js.

_handleSetRequestPinned internally calls App._updateRequestMetaByParentId, which is the same one used by the other handlers and supports getOrCreate. If it is a new request (with no meta) then this handler also creates meta.

https://github.com/getinsomnia/insomnia/blob/d8066bc55887b865c359a8f8815c44c9f7bdf325/packages/insomnia-app/app/ui/containers/app.js#L388-L396

Ya I saw that. I thought your first comment was about the complexity of finding the request meta in the entities list.

I was suggesting using getOrCreate instead of having to write the manual filter on the entities list

develohpanda · 2019-05-04T07:32:04Z

packages/insomnia-app/app/ui/redux/selectors.js

+          };
+
+          if (child.pinned) {
+            pinnedChildren.push(child);


I did this for efficiency. Extracting all pinned requests (ie. nested requests) in sidebar-children would require an extra unnecessary traversal of childrenTree.

I think it actually fits well here within the context of "sidebar children" since the only place it's used is in the sidebar. If/when pinned requests are needed elsewhere, this would make less sense. For now, it's good though.

gschier

Just a few comments

gschier · 2019-05-04T14:50:14Z

packages/insomnia-app/app/ui/components/sidebar/sidebar-children.js

+  pinned: Array<Child>,
+  all: Array<Child>,
+};
+


I'm okay with it here. It makes sense to have it defined where it's used.

gschier · 2019-05-04T15:07:34Z

packages/insomnia-app/app/ui/containers/app.js

+            this.props.activeRequest,
+            !(metas[0] && metas[0].pinned),
+          );
+        },


We'll need to keep pinned on RequestMeta. The "meta" models are meant to store information that isn't related to actually sending the request and also that should not be synced or shared.

Note. One thing that would help here is using the getOrCreateByParentId method on request-meta.js.

gschier · 2019-05-04T15:07:49Z

packages/insomnia-app/app/ui/containers/app.js

+            this.props.activeRequest,
+            !(metas[0] && metas[0].pinned),
+          );
+        },


Also, you'll need to add a check to make sure activeRequest is not null

gschier · 2019-05-04T18:42:03Z

packages/insomnia-app/app/ui/redux/selectors.js

+          };
+
+          if (child.pinned) {
+            pinnedChildren.push(child);


I think it actually fits well here within the context of "sidebar children" since the only place it's used is in the sidebar. If/when pinned requests are needed elsewhere, this would make less sense. For now, it's good though.

gschier · 2019-05-04T18:45:29Z

How should the filter behave with pinned requests? IMO pinned items should not be affected by filters and should always be visible.

I'll leave this one up to you. I think both ways make sense. We'll leave it to future feedback to tell us if we made the wrong choice

Given pinned items are to show in both places, should the pin icon also show in both places (or only in the pinned list at the top)?

I think in both places makes sense 👍

gschier · 2019-05-04T18:53:05Z

packages/insomnia-app/app/common/hotkeys.js

@@ -288,6 +290,11 @@ const defaultRegistry: HotKeyRegistry = {
    keyComb(true, false, false, false, keyboardKeys.d.keyCode),
  ),

+  [hotKeyRefs.REQUEST_TOGGLE_PIN.id]: keyBinds(
+    keyComb(false, false, false, true, keyboardKeys.p.keyCode),


Mac key comb should probably be false, false, true, true to map to Cmd+Shift+P because Cmd+P already maps to the request switcher. Windows/Linux one is fine though with what you have (Ctrl+Shift+P)

develohpanda · 2019-05-04T23:43:29Z

Ready again!

gschier

Just one small thing!

gschier · 2019-05-05T22:47:54Z

packages/insomnia-app/app/ui/containers/app.js

+          if (!this.props.activeRequest) {
+            return;
+          }
+
          const metas = Object.values(this.props.entities.requestMetas).filter(


Should be using .find() instead of .filter()

TIL. Will update this evening!

gschier

Looks good now! Thanks so much for your hard work on this one 😄 💯

develohpanda added 18 commits April 25, 2019 22:34

Add pinning behavior

5c50c87

add fa-thumb-tack

c279d9d

Merged with develop

4675d5b

Updated package-lock files

dd02a96

Allow only top level request and request group to be pinned

5f9514e

Prevent dnd for pinned request

e4f5882

Efficiency change

249a0fa

Reverted changes

e47fe11

Revert changes to selectors.js

163fc7e

Fixed pin and add thumbtack

af9075d

Changes

3465501

Pin styling

dba476e

Fix overflow bug

76e64a4

styling complete

e53999b

Remove additional style

a3238a6

Updated package-lock.json

2b8b950

Merge branch 'develop' into feature/pinned-request

b8b9879

Mergie

ee403f9

gschier reviewed Apr 27, 2019

View reviewed changes

packages/insomnia-app/app/ui/components/sidebar/sidebar-children.js Outdated Show resolved Hide resolved

develohpanda added 2 commits April 27, 2019 22:52

Boolean to boolean

e8079a2

allow nested requests to be pinned

aca9a95

Remove unused arg

d0232fd

Remove folder pinning functionality

6d0d30e

Remove comment

174c1eb

develohpanda changed the title ~~Support for pinned requests and folders~~ Support for pinned requests Apr 28, 2019

Revert change to open tag on group

4684fef

gschier suggested changes Apr 30, 2019

View reviewed changes

develohpanda added 2 commits May 4, 2019 16:14

Render separator with dsiplay: none so that sync menu is in correct p…

b1da85f

…lace

Don't reset parent id on request pin

05c8e17

develohpanda added 6 commits May 4, 2019 16:45

Remove extra checks

2ce8d12

Move pin filter to selectors to prevent duplicate childTree traversal

7e6ce57

Decouple pinned items from search results

8938e9b

Hide pin on hover

b18447c

Pin keyboard shortcut via shift+ctrl+p

6ab94d2

Typo fix

3fc894e

develohpanda commented May 4, 2019

View reviewed changes

gschier suggested changes May 4, 2019

View reviewed changes

gschier reviewed May 4, 2019

View reviewed changes

Update mac hotkey + activeRequest nullcheck

278b2fb

Disable drag and drop only for items in the pinned list

3461fb9

gschier suggested changes May 5, 2019

View reviewed changes

Filter to Find

cc394f8

gschier approved these changes May 7, 2019

View reviewed changes

gschier merged commit c48daae into Kong:develop May 7, 2019

develohpanda deleted the feature/pinned-request branch May 7, 2019 22:18

Support for pinned requests #1471

Support for pinned requests #1471

Conversation

develohpanda commented Apr 27, 2019 • edited Loading

Features

Screenshots

gschier commented Apr 27, 2019

develohpanda commented Apr 27, 2019 • edited Loading

gschier commented Apr 27, 2019

develohpanda commented Apr 27, 2019

rickychandra commented Apr 30, 2019

develohpanda commented Apr 30, 2019

rickychandra commented Apr 30, 2019

develohpanda commented Apr 30, 2019

gschier commented Apr 30, 2019

gschier left a comment

Choose a reason for hiding this comment

develohpanda commented Apr 30, 2019

gschier commented May 1, 2019

develohpanda commented May 4, 2019 • edited Loading

develohpanda left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

develohpanda May 4, 2019 • edited Loading

Choose a reason for hiding this comment

develohpanda May 4, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gschier May 5, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gschier left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gschier commented May 4, 2019

Choose a reason for hiding this comment

develohpanda commented May 4, 2019

gschier left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gschier left a comment

Choose a reason for hiding this comment

develohpanda commented Apr 27, 2019 •

edited

Loading

develohpanda commented Apr 27, 2019 •

edited

Loading

develohpanda commented May 4, 2019 •

edited

Loading

develohpanda May 4, 2019 •

edited

Loading

develohpanda May 4, 2019 •

edited

Loading

gschier May 5, 2019 •

edited

Loading