-
Notifications
You must be signed in to change notification settings - Fork 54
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: Fidelity bonds in developer mode #221
Conversation
2aee16e
to
cc74b4f
Compare
Converted to draft. Will update "dark mode" and remove "Advanced Mode" toggle. |
Updated:
Everything said before is still true:
Needs a review. |
<Link className="unstyled" to={routes.fidelityBondsDevOnly}> | ||
Switch to developer view. | ||
</Link> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly I don't think we need that extra step. It's already only in "advanced" mode (which is called developer mode in the app already). Once the user is here I'd say we can let them do their stuff. No need for the extra hurdle imo. What do you think about it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need two distinct modes. As a developer, I want to have access to the actual timelock address, which does not necessarily need to be exposed to a user ever. Do you have a preferred way to do this or do you have different mechanism in mind?
Having a dedicated view for local development seemed to be the easiest solution to me.
e.g. Creating Fidelity Bonds in the past – a user should never be able to do that.. in development it is very useful, though.
return ( | ||
<rb.Row> | ||
<rb.Col xs={6}> | ||
<rb.Form.Group className="mb-4" controlId="locktimeYear"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a shame that Firefox still doesn't support the "month" date picker. It's been tracked for over 9 years... Same for Safari.
Anyway what do you think of a dropdown here? At least for the months a 12 value dropdown is something users will know from most websites. The same applies to the year as well I guess. Most users won't pick a date several decades ahead (I guess) so the year will be accessible quickly in the dropdown.
Longer term, we should go with a nice date picker of course but this can be an improvement. Shame on you Firefox and Safari.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we implement something like this?
Source: https://www.primefaces.org/primeng/calendar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
found this, maybe it helps: https://raygun.com/blog/building-great-looking-useable-date-time-picker-without-bootstrap/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we implement something like this?
Not out of the box unfortunately since Firefox and Safari don't support the default HTML "month-only" date pickers (see links above for more details).
We can (and should) certainly do something custom or use a library but that's definitely something for a separate PR.
const dateToLockdate = (date: Date): Api.Lockdate => | ||
`${date.getUTCFullYear()}-${date.getUTCMonth() >= 9 ? '' : '0'}${1 + date.getUTCMonth()}` as Api.Lockdate | ||
|
||
const lockdateToTimestamp = (lockdate: Api.Lockdate): number => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These two would be ideal for some unit tests.
const [lockdateMonth, setLockdateMonth] = useState(currentMonth) | ||
|
||
useEffect(() => { | ||
const date = new Date(Date.UTC(lockdateYear, lockdateMonth - 1, 1, 0, 0, 0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const date = new Date(Date.UTC(lockdateYear, lockdateMonth - 1, 1, 0, 0, 0)) | |
const date = new Date(Date.UTC(lockdateYear, lockdateMonth - 1, 1)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comes up quite often and not forgetting the - 1
part is critical. Should we move this to a function?
What do you think of adding a "deposit"/"send"/"lock" button to the form so that the user doesn't have to go to the Send page? That way the fidelity bond feature would be self contained (Even though some API calls will have to be duplicated from the Send page. But that's fine imo.) |
I think it was a rough first poc with the generation of the address. we should do all the magic behind the curtain. no Manuel sending, don't you think? |
Yes definitely. We can obviously also split that up into several PRs if you prefer that @theborakompanioni. Anything goes, it's behind a feature flag anyway :) |
Hey guys, thank you very much for your feedback. I'll try to integrate it soon and will keep all things said here in mind while working on #307 today. Will ping you, once updates were made. |
Co-authored-by: Daniel <[email protected]>
b4bedff
to
784ae27
Compare
Closing this in favor of #307 and try to address all feedback there. |
Part of #31.
This PR contains a minimalist screen to create Fidelity Bonds in advanced mode.
It is behind a feature flag that is only activated for local development.
Fidelity Bonds for normal mode is a bit comprehensive and is done in follow-up PR.
Currently, a link from the
CurrentWalletAdvanced
view leads to a simple form that let's users choose the locktime and will subsequently display the corresponding address. As this is in advanced mode, a user can then manually fund this address by himself.In the normal mode, the fidelity bond should be created automatically.
Early state. This is just a proof of concept. All feedback very welcome.
Keep in mind that it is still hidden behind a feature flag!
jamjamjam_fb_create_advanced.mp4
It would be great to have this merged for local development, even if it is not fully polished yet (e.g. some translation strings are missing).