[F] Improve Journal + Project Collection Discoverability

[1aurend]

@dananjohnson @jen-castiron here's the branch with the updated library route structure. For project collections, I added redirects at the old paths to keep existing bookmarks working and updated the redirects in and out of admin.

[dananjohnson]

Thanks, Lauren!

[dananjohnson]

@1aurend @jen-castiron this is looking good so far! I'll think a bit more about the project collections thumbnail, but here's some feedback to address in the meantime.

[dananjohnson]

@jen-castiron a couple changes here:

• The collecting toggle shouldn't show up for project collections. They can't actually be collected.
• Can we show some metadata here for journals and project collections? Projects show "Updated at…", which might be nice at the very least.

[dananjohnson]

Thinking more about metadata, it might be neat for journals if we construct a range of issues, like "Vol 1, Issue 1 – Vol 4, Issue 6". There's some logic in EntityMetadata that could be abstracted perhaps.

For project collections, could we list the number of projects?

[dananjohnson]

The more I look at EntityMetadata the more I wonder if it needs a bit of a refactor. There's a lot of shared stuff between entity types, especially UI-wise, but we might want to rethink getMetadataProps before adding even more logic to it.

[jen-castiron]

I see what you mean! I'll take a look at that wrapper and component and see what we could do to make it a little more generic.

[jen-castiron]

We talked about this in FE confab - changes have been pushed! If we want more information on journal / project collection thumbnails, we'll need to add more data to the entity properties.

[dananjohnson]

Since this is a global generic component, I wonder if we should just make the route name a prop.

[jen-castiron]

I understand your concern, but this component isn't truly generic. It is generic to entities, which have a type and a specific route name. (The component originally went to "frontendProjectDetail", no matter what entity you gave it.) Since this component gets the full entity object with type, it seemed unnecessary to made a developer pass in the route name.

I could see passing in the route name if there's a chance we want the preview to go somewhere other than the entity type's detail page.

Edit: I'm taking a look at this as part of the EntityThumbnail / EntityMetadata refactor

[jen-castiron]

@dananjohnson @1aurend
General question on the Manifold linter... I've run into no-nested-ternary issues quite a bit, and noticed they get turned off in some places. We don't have that rule on our other projects - is it worth keeping around?

[dananjohnson]

@dananjohnson @1aurend General question on the Manifold linter... I've run into no-nested-ternary issues quite a bit, and noticed they get turned off in some places. We don't have that rule on our other projects - is it worth keeping around?

I don't love nested ternaries but am not an absolutist about it. I think my rule would be: nesting once is fine, but if you're doing more than that, find another solution like a switch. Otherwise it just gets too hard to read.

[1aurend]

I noticed one odd thing on the project collections page. When I first open it, the "reset filters" button is showing:

But then if I click reset, all my collections show up, even the ones with visible=false:

[1aurend]

@dananjohnson @1aurend General question on the Manifold linter... I've run into no-nested-ternary issues quite a bit, and noticed they get turned off in some places. We don't have that rule on our other projects - is it worth keeping around?

I don't love nested ternaries but am not an absolutist about it. I think my rule would be: nesting once is fine, but if you're doing more than that, find another solution like a switch. Otherwise it just gets too hard to read.

While I agree there's a limit, I end up disabling this lint rule a lot. I'm all for removing it.

[1aurend]

These counts also really don't make sense as a user who can't see drafts:

Anyhow... just pushed a couple of commits adding the keyword filter to project collections and exposing some more counts. I went with available_[type]_count that reflects how many the current user can access rather than a straight published count. Let me know if something different would be better.