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

feat: Refactor of the power calculator store #43

Open
wants to merge 74 commits into
base: master
Choose a base branch
from

Conversation

threkk
Copy link
Collaborator

@threkk threkk commented Jun 23, 2021

TODO

The new source of truth is the store and the refactor avoids the data duplicity.
…visitors per day calculation for non-inferiorty.
The integration was having some issues when importing props. With this
patch:
- It will use only the actual format for the prop import instead of
  supporting the old format. It is up to the integration layer to adapt
  it.
- Once the values are imported, it will automatically refresh possible
  missing values and emit an event with the new values.
Copy link
Collaborator

@arrudaje arrudaje left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, most of my comments are just CTRL+C CTRL+V, so don't panic 😅

>
<pc-svg-chain :isBlockFocused="isBlockFocused"></pc-svg-chain>

<div class="pc-header" v-if="testType == 'gTest'">Base Rate</div>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not === ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly this is code that already was like that and I didn't really touch, just formatting. However, it is a good point, and will get fixed.

<li class="pc-input-item pc-input-left">
<label>
<span class="pc-input-title"
>{{ testType == 'gTest' ? 'Base Rate' : 'Base Average' }}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not === ? Also, if we expect this condition to repeat, shouldn't we wrap it in a computed property?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

</label>
</li>

<li class="pc-input-item pc-input-sd-rate" v-if="testType == 'tTest'">
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

=== ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same.

:fieldValue.sync="sdRate"
:isReadOnly="isReadOnly"
:isBlockFocused="isBlockFocused"
enableEdit="true"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't use the raw property, this assigns the prop as string, and not boolean as it's the original intention. If we decide to modify this to false it will not have the intended effect. Just add the : to the beginning of the prop name.

return this.$store.getters.baseRate
},
set(val) {
if (this.baseDebouncer != null) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here you also should make the comparison strict, as the baseDebouncer is defined initially with null so it will not become undefined

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The normal uneven comparison is a trick: it checks that the value is not null or undefined. Strict check will return true for undefined.

}
},
getLockedStateClass(param) {
return this.lockedField == param
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

=== ?

fieldProp="variants"
prefix="base + "
:fieldValue.sync="variants"
enableEdit="true"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Raw property~

suffix="%"
fieldProp="falsePositiveRate"
:fieldValue.sync="falsePositiveRate"
enableEdit="true"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Raw property~

:class="{ 'pc-top-fields-error': power < 80 }"
fieldProp="power"
:fieldValue.sync="power"
enableEdit="true"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Raw property~


<div
class="pc-blocks-wrapper"
:class="{ 'pc-blocks-wrapper-ttest': testType == 'tTest' }"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

=== ?

Copy link
Collaborator

@arrudaje arrudaje left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

threkk added 18 commits June 25, 2021 11:30
…the adjusted value

When the distribution is binomial, the scale of the base rate is adjusted from
normal value to percentage value to match the display of the value.
However, the value used to calculate the missing value of the
relative/absolute pair was using the original one instead of the
adjusted.
…odes

During the last refactoring of the power calculator, one of the rules we
imposed ourselves was to respect user input. This is, if the user wrote "400",
after switching it would still be "400", but changing the equivalent internally
from "400 units" to "400%".

The best solution is to remove the % symbol in the binomial metrics. That way,
we don't need to transform the internal values for the user input to stay the
same, and will avoid user confusion.
This reverts part of the commit 374ceb8, but
keeps the original purpose.
…nferiority tests and its effect on the false positive rate
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants