Problem/Motivation

See #3618286: List "Flippy" as simpler (less powerfull) alternative?

Seems like they already solved a lot of the 3.x points, but maybe don't have all the flippy features yet plus not that simple UX?

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

anybody created an issue. See original summary.

anybody’s picture

Title: [3.x] Join forces with entity_pager? » [3.x] Join forces with entity_pager? (Instead of 3.x)
joachim’s picture

> but maybe don't have all the flippy features yet plus not that simple UX?

It's true that Entity Pager requires you to create a view for your pager, so to create the same thing as Flippy, you'd need to create a view, add a node type filter, and then place the block.

I'm looking at adding computed field support so the pager outputs as a field -- #3619359: add Computed Field support.

As for pager creation DX, we could feasibly add an admin UI that creates a template view for an entity bundle pager.

joachim’s picture

> As for pager creation DX, we could feasibly add an admin UI that creates a template view for an entity bundle pager.

It's a shame that there's no longer the default views hook, as that would be one way to do it.

joachim’s picture

Spurred on by this, I've started working on a module for fixed config. It's something I've had on my mind for a long time.

It would allow this module to depend on Entity Pager, and then define derived fixed config which automatically makes a view for each node type.

anybody’s picture

Thanks @joachim please keep us updated here. We're open for any useful path.

Still I think if joining forces with entity_pager I'd fully like to deprecate flippy (and if possible provide an update path here).

joachim’s picture

I was thinking Flippy could stay as a project that depends on Entity Pager, to provide automatically-configured node type pagers.

anybody’s picture

@joachim Yes, I’d already thought you might mean that, but I believe it would be better for users if they only had to use `entity_pager` and the relevant functions were integrated into it. I think Flippy would then become obsolete and can be deprecated.

joachim’s picture

With Composer for package installation and a dependency for Drupal installation, it would be transparent to users - they'd just install Flippy as they currently do.

I wouldn't want it in the main Entity Pager module, and the problem with having it as a submodule is that it will have Fixed Config as an additional dependency, so Composer won't install it.