Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REF} User api rather than selector for rendering contributions on user dashboard #13584

Merged
merged 1 commit into from
Feb 13, 2019

Conversation

eileenmcnaughton
Copy link
Contributor

Overview

This is a code cleanup on the user dashboard for readability, testing & performance reasons

Before

Selector invoked

After

api invoked - no user change

Technical Details

Note that preliminary tests for this were written & merged some time ago.

Reasons for the change are

  1. readability - most devs are much more comfortable with reading the api code than the selector
  2. performance - the contribute selector code is deeply unperformant - mostly due to the summary function which in
    this case is somewhat mitigated by the limit of 12 but we are still doing something slow for no reason
  3. test stability - the test for this turned out to have poor stability & hopefully this will help
  4. preliminary cleanup - there are 2 existing PRs that attempt to add new buttons to this & moving towards
    a cleaner tpl / php layer will help with those. In addition there is a serious performance issue to
    address on the contribution summary function. Reducing use of that function should help with the cleanup effort

Comments

@civibot
Copy link

civibot bot commented Feb 13, 2019

(Standard links)

@civibot civibot bot added the master label Feb 13, 2019
@eileenmcnaughton
Copy link
Contributor Author

test this please

…et contributions to display.

Note that preliminary tests for this were written & merged some time ago.

Reasons for the change are

1) readability - most devs are much more comfortable with reading the api code than the selector
2) performance - the contribute selector code is deeply unperformant - mostly due to the summary function which in
this case is somewhat mitigated by the limit of 12 but we are still doing something slow for no reason
3) test stability - the test for this turned out to have poor stability & hopefully this will help
4) preliminary cleanup - there are 2 existing PRs that attempt to add new buttons to this & moving towards
a cleaner tpl / php layer will help with those. In addition there is a serious performance issue to
address on the contribution summary function. Reducing use of that function should help with the cleanup effort
@eileenmcnaughton
Copy link
Contributor Author

Added has-test as the tests were written & merged in preparation for this (but I pushed this change out due to difficulties there - which have continued with the 'bounciness' of this test

@seamuslee001
Copy link
Contributor

(CiviCRM Review Template WORD-1.2)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants