Resolve contract from ens name #11055
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Jenkins BuildsClick to see older builds (14)
|
|
@Ferossgp @Serhy Adding expected behavior here as guidance for testing Expected behaviorWhen ENS name in backend service is empty:
|
|
Check ahead of release 1.6 which is to include advertiser flow for referral program only (based on new contract) plus only high-prio fixes that would otherwise go into a Does this PR include any dependencies on |
If we want that behavior then it means the feature should be toggle from backend, ENS can be used as a kill switch to all program cc @andremedeiros |
Ferossgp
commented
Aug 18, 2020
flexsurfer
reviewed
Aug 18, 2020
| {::json-rpc/eth-call [{:contract contract | ||
| :method "getDefaultPack()" | ||
| :outputs ["address" "uint256" "address[]" "uint256[]" "uint256[]"] | ||
| :on-success #(re-frame/dispatch [::starter-pack-amount (vec %) (prn %)])}]}) | ||
|
|
||
| (re-frame/reg-sub-raw |
There was a problem hiding this comment.
could you please elaborate on this? why would you want to have raw subs and dispatch from them
There was a problem hiding this comment.
This is a nice approach to use just subscription for external data, this way we do not need to trigger events on some actions but they will be triggered when the data is requested by the subscription. There is a similar example in the docs https://github.com/day8/re-frame/blob/master/docs/Subscribing-To-External-Data.md#some-code
There was a problem hiding this comment.
i'm not sure i understand the reason why you can't dispatch event in the place where you set value in app-db ? i mean the cool thing about re-frame its simple, and predictable, this one just looks like can be done in "regular" way but just adds one more case for devs to know an remember , not sure if it worth it
There was a problem hiding this comment.
for me it looks like unpredictable thing, i don't expect that event will be dispatched when i use subscription, instead i'll be looking to component-will-mount
There was a problem hiding this comment.
probably if we really want to use this approach at least we could give a names for such subscriptions, like ::get-starter-pack-and-dispatch
There was a problem hiding this comment.
Well, that's described in re-frame documentation, so it is correct in terms of the re-frame flow. The problem with the dispatching event is that we show it in 3 places, and we need then to dispatch it every time before showing any of these screens. Also as a user of API, you should no care from where this data is resolved. Mostly you will look at this subscription as "give me the starter pack" and the subscription will give you the value. The underline implementation makes sense only if you want to change it. But as this event doesn't involve data mutation it can be interpreted as a pure pulling of data.
Dispatch actually is not needed here at all, I can call the fx directly, the dispatch call is here because firstly it was implemented with dispatch during navigation to the invite screen, then refactored to raw when it became needed in other places. So I think I can remove the dispatch by replacing it with the fx call directly, and keep the name as it is.
flexsurfer
reviewed
Aug 19, 2020
| @@ -248,7 +247,7 @@ | |||
| (i18n/label :t/invite-reward {:value (str (get reward :eth-amount) " ETH")})]])]]))) | |||
|
|
|||
| (defn list-item [{:keys [accessibility-label]}] | |||
| (if-not config/referrals-invite-enabled? | |||
| (if-not @(re-frame/subscribe [::events/enabled]) | |||
There was a problem hiding this comment.
events looks too general, probably ::invite.events could work better
| (fn [] | ||
| (get-in @db [:acquisition :starter-pack :pack])))))) | ||
|
|
||
| (re-frame/reg-sub |
There was a problem hiding this comment.
we still don't have a decision on moving subs from subs.cljs
There was a problem hiding this comment.
Yes, but I wanted to keep the referral program code fully isolated from the app, as we do not know how it will evolve later, and how much time it will be there.
| {::json-rpc/eth-call [{:contract contract | ||
| :method "getDefaultPack()" | ||
| :outputs ["address" "uint256" "address[]" "uint256[]" "uint256[]"] | ||
| :on-success #(re-frame/dispatch [::starter-pack-amount (vec %) (prn %)])}]}) | ||
|
|
||
| (re-frame/reg-sub-raw |
There was a problem hiding this comment.
i'm not sure i understand the reason why you can't dispatch event in the place where you set value in app-db ? i mean the cool thing about re-frame its simple, and predictable, this one just looks like can be done in "regular" way but just adds one more case for devs to know an remember , not sure if it worth it
| {::json-rpc/eth-call [{:contract contract | ||
| :method "getDefaultPack()" | ||
| :outputs ["address" "uint256" "address[]" "uint256[]" "uint256[]"] | ||
| :on-success #(re-frame/dispatch [::starter-pack-amount (vec %) (prn %)])}]}) | ||
|
|
||
| (re-frame/reg-sub-raw |
There was a problem hiding this comment.
for me it looks like unpredictable thing, i don't expect that event will be dispatched when i use subscription, instead i'll be looking to component-will-mount
| {::json-rpc/eth-call [{:contract contract | ||
| :method "getDefaultPack()" | ||
| :outputs ["address" "uint256" "address[]" "uint256[]" "uint256[]"] | ||
| :on-success #(re-frame/dispatch [::starter-pack-amount (vec %) (prn %)])}]}) | ||
|
|
||
| (re-frame/reg-sub-raw |
There was a problem hiding this comment.
probably if we really want to use this approach at least we could give a names for such subscriptions, like ::get-starter-pack-and-dispatch
flexsurfer
approved these changes
Aug 19, 2020
1% of end-end tests have passedFailed tests (96)Click to expand
Passed tests (1) |
Ferossgp
force-pushed
the
ens-contract-referrals
branch
from
67a6a83
to
40f6e9a
Compare
|
Thanks you, @Ferossgp |
Do not show referrals if contract is not available Do not check contract for referral accept Rename invite event namespace require Remove dispatch from raw subs Do nothing if there is no contract Signed-off-by: Gheorghe Pinzaru <feross95@gmail.com>
Ferossgp
force-pushed
the
ens-contract-referrals
branch
from
40f6e9a
to
c644ab3
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Use ENS name for the acquisition contract. So it can be switched or removed dynamically without store release. Also checks for referrals after login, as the network is not available before and we cannot fetch the ens name