Only re-render the table / fire rowsReceived hook when needed

[edwinvdpol]

Hi there,

With every action you do on the table (filtering, column toggling), the full table is re-rendered.

Most of the time, this makes sense.. But...

When you, for example, toggle a column, this is not strictly needed imo.

I hooked into the rowsRetrieved hook in my project, to let other components know that the table data is updated.
Because of this, all components will re-render while the data didn't change.
This can cause unnecessary API requests (in my case).

Do you have any idea on how to prevent this?

Are you open for a PR, which will work kind of like the setClearSelectedOnSearch for example?

For instance:setRenderOnColumnToggle, or to keep things flexible setCallRowsRetrievedHook to prevent the hooks being fired?

setCallRowsRetrievedHookStatus(bool $status);
setCallRowsRetrievedHookEnabled();
setCallRowsRetrievedHookDisabled();

Maybe something else, just my thoughts right now.

What do you think?

-- Edwin

[lrljoe]

I'm happy for a PR for toggling lifecycle hooks.

I'd suggest a format of

setLifecycleHookRowsRetrievedStatus(bool $status);
setLifecycleHookRowsRetrievedEnabled();
setLifecycleHookRowsRetrievedDisabled();

So that the same naming convention can be re-used elsewhere.

Worth noting - the package intentionally re-renders the table when toggling a column. Typically, the package will only retrieve the data for SELECTED columns.

So it will require re-rendering to update the query if you "select" a Column that it doesn't hold the data for.

The reason for this, is that some people have complex/large columns, and don't want that data retrieved typically, but may want it retrieved ad-hoc.

[lrljoe]

Looking at this again, given that the table intentionally minimises the query, I can't see a sensible, easy way to avoid a re-render, particularly as there are a lot of users out there with published views.

Getting all data for all columns, regardless of select status would be impactful, so it'd have to be default off, with a rewrite of the existing logic to allow for unselected columns to be optionally added in.
Then there'd need to be additional logic to swap between frontend methods, and backend methods to toggle column select/visibility.

Keep in mind that the selected columns is used to return and render the columns, that there are callbacks, which may be complex (thus the column may be deselected by default)

If a PR is created that
a) Does not impact existing deployments
b) Has full tests
c) Sensibly handles existing behaviour, and sensibly allows for new behaviour
d) Allows all existing methods for Columns
e) Does not impact performance beyond what would be expected from additional db queries

Then I'm all for it.

Seems like it might be more work than you initially thought tho!