drips-network / app Goto Github PK

A flow that allows the user to create a new stream from the given account.

Designs: https://www.figma.com/file/vyI7f996JF8zwhnXwAwXdC/Drips-App-V2?node-id=110%3A4756

🛑 Blocked by "Streams section"

Currently, our incoming balance estimation logic only shows the cumulative total of all money earned from incoming streams, but does not consider the recipient collecting funds, nor incoming funds from splits or gives.

Ideally, we want to show the current real-time balance if the user were to squeeze all their incoming drips, including funds from incoming splits and gives that are splittable, before splitting, as the incoming balance on the dashboard. Consequently, after a full collect interaction (squeeze -> receive -> split -> collect), the incoming balance on the dashboard should drop to zero, and start updating every 100ms with newly-earned incoming funds from streams, if any.

Currently, we're writing Playwright E2E tests, but use Vitest as our test runner for both unit- and E2E-tests. Vitest is excellent for unit testing, but when using it as a test runner for Playwright tests, certain Playwright features like the test inspector and codegen functionality don't work.

The Balances section lists the user's current balances (incoming & outgoing balances) by token, and acts as an entry point to topping up, collecting or withdrawing amounts.

Designs: https://www.figma.com/file/vyI7f996JF8zwhnXwAwXdC/Drips-App-V2?node-id=169%3A5354

🛑 Blocked by "Streams store"
🛑 Blocked by "Balances store"

The drips animation currently renders at the native resolution of the current display, which is quite taxing for low-power devices. Just capping the max resolution multiplier to 2x is probably enough to make it smooth on all devices.

maybe link to a whole page of them

Sometimes, when you're currently connected to MetaMask, it appears that the disconnect event handler doesn't fire when the user disconnects from within metamask (?), causing the user to stay on the dashboard. What should happen is wallet.connected becoming false, and the user being redirected to the connect page.

In order to avoid confusion about the end date being translated to a duration relative to the stream creation timestamp (which we cannot accurately predict upfront), let's change the create stream flow to accept a specific end date only in combination with a specific stream start date. This ensures that the end date is always relative to the specified start date, avoiding the stream end date shifting relative to the transaction confirmation timestamp. In addition, a warning notifies the user that the stream may start after the configured start date, if said date is before the transaction's on-chain confirmation timestamp.

Currently, you can't change the value of the dropdown with keyboard navigation, which is a small accessibility issue. We can open a PR to radicle-design-system to make this component work with keyboard navigation.

If you don't have any splits config, it currently shows "Splitting 0" (the zero is where usually the split-away percentage would appear). Additionally, the wording of the step description is a tad awkward — you "currently" don't have any funds to collect this cycle, yes, but you'll never have any funds to collect this cycle, not just "currently".

The address value should only be set once a valid address is set (either from resolving ENS or direct input), in order to avoid some random text showing up in the stream create animation, which is expecting an address value.

The Streams section lists all the current account's streams, both incoming and outgoing, based on data from the Streams store. It acts as an entrypoint to viewing stream details. All balances are displayed in real-time.

Initially, it is grouping streams by direction and cannot be filtered, though in the future we may consider adding other grouping options and allowing the user to flexibly filter the table.

Designs: https://www.figma.com/file/vyI7f996JF8zwhnXwAwXdC/Drips-App-V2?node-id=169%3A5354

🛑 Blocked by "Streams store"
🛑 Blocked by "Balances store"

A component used on the Dashboard as a header for the different sections. Icon, label and actions should be customizable.

Right now, the app only mounts content after the wallet store is fully initialized. Sometimes, this process includes asking the user to switch to the right network through their connected wallet. If the user for some reason misses this request, they're just looking at a blank screen in the app, not knowing why. We should have some kind of UI while the app initializes, and also show "please switch network to x" while a network change request is pending.

Currently, dripId is randomly generated upon stream creation, with 4 bytes of entropy. This has a relatively high chance of collision (still small, but a bit too high to be comfortable). Let's add some logic for checking all on-chain and off-chain stream's IDs for collisions before settling on a random dripId.

first draft

A store that:

• Exposes the collectable and outgoing balance amounts for all tokens held by the current account
• Calculates real-time balance estimates within the current cycle for all outgoing and incoming streams of the given account

🛑 Blocked by "Tokens store"
🛑 Blocked by "Streams store"

A global store that allows querying ENS info for any address, and caches said information to avoid excessive requests.

Currently, the top-up flow does not pull the user's current wallet balance of a selected ERC-20, and allows inputting any amount value. If the balance is too high, it will simply display a pretty verbose transaction revert error. We should pull the user's balance and warn straight on the amount step if the amount is too high.

New text, from Ele:

"One Contract. One Payment Graph."

"Drips utilizes only one smart contract behind the scenes, for both streaming and splitting funds. This allows users to effortlessly route funds between accounts in a very flexible way."

Current text:

A global store that fetches metadata for the current account, and exposes a list of individual streams including name, description, and stream config. It also automatically determines and fetches all incoming streams to the current account, including metadata.

Adds the basic layout of the app, including sticky header, wallet button, skeleton for the account menu, logo, and page margins.

A store that:

• exposes a default token list, multi-chain
• serves token icon URLs
• Allows adding and deleting custom tokens
• Stores and serves custom tokens from localstorage
• Allows banning and unbanning custom tokens

A flow that allows the user to withdraw funds from a given token's outgoing balance.

Designs: https://www.figma.com/file/vyI7f996JF8zwhnXwAwXdC/Drips-App-V2?node-id=140%3A6124

🛑 Blocked by "Balances section"

#49 added a simple collect modal which simply displays the receivable, streamable, and splittable income as reported by the contract, and triggers the appropriate transactions to receive, split and collect.

This is missing two major features that we're aiming for in the MVP: Squeezing, and breaking down incoming income to earned by streams, incoming splits, and gives.

Blocked by #62

This section isn’t linked up to anything and is a bit irrelevant

• The Drips team presented at DevCon 22
• Drips JS-SDK ready for use!
• Version 0.2 released
• Drips get-together at EthCC
• The alpha version of our SDK is released
• Protocol v2 now on Goerli Testnet

We should autofocus on the first input in any given step automatically on the stepper level. This would improve accessibility for people using keyboard navigation, and UX for everyone.

Add a global store that initialises and exposes various clients from the Drips JS SDK so that we can use them across the app.

Currently, our pinata gateway can be used by anyone from any site. I think it's possible on the Pinata dashboard to set specific hosts that should be allowed to use the gateway.

Currently, our Stream Create flow allows setting any arbitrary "Stream End Date" (the field accepts only a date down to the day level, no specific time input). This basic implementation has a few shortfalls:

• It is unclear which timezone the end date is set in.
• It is impossible to end the stream at a specific time on a specific day.
• You cannot set a start date.
• The end date behind the scenes is converted to a duration in seconds, relative to the moment the user clicks "Create stream". In reality, the duration is relative to the block timestamp of when the setDrips transaction is first confirmed, which could lead to the stream ending at a significantly different time vs what was intended. This problem is especially pronounced when using a Gnosis Safe, which might confirm the transaction only a long time after it was initially proposed.
• You cannot currently choose to stream a specific amount of the selected token. It should be possible to enter a target amount, and automatically calculate the stream duration given the input target and amount per second.

Given all the above, we should design a second iteration of the Create Stream modal that addresses all these concerns, allowing the user to set a start and end date manually, but also specify an intended target amount resulting in an automatic duration. In all cases, the modal should warn the user about the duration being relative to transaction execution, and suggest setting a start date sufficiently in the future to avoid an unexpected shift in stream duration if the user specifies an end date.

It's pretty unclear what these are at the moment. Tooltips (like in the design) next to the two columns would help explain.

A dropdown that appears when hovering over the currently connected wallet button in the top right.

It allows:

• Opening the settings screen
• Switching between supported networks of the Drips app
• Disconnecting the current wallet

Currently, the wallet store is undefined until a wallet is connected. Because all information should be readable from the Graph without requiring a provider at all, we should be able to offer a read-only experience without requiring a wallet connection. For this, let's change the wallet store to initialise with a default network (later, we can add a network picker).

A flow that allows the user to collect earned funds.

Designs: https://www.figma.com/file/vyI7f996JF8zwhnXwAwXdC/Drips-App-V2?node-id=232%3A6108

🛑 Blocked by "Balances section"

A flow that allows the user to top-up any ERC-20 token to a given Drips account.

Designs: https://www.figma.com/file/vyI7f996JF8zwhnXwAwXdC/Drips-App-V2?node-id=110%3A4755

🛑 Blocked by "Balances section"

We should probably just set the height to auto after the initial height animation.

Need to look into whether these work properly on drips, and whether they're included in the uniswap default token list. We may need to publish our own token list without these tokens included.

A general UI component for rendering a table that can handle all the usecases we have for tables across the design (streams list, tokens list, etc.)

A settings screen that allows the user to:

• Adjust theming (appearance) of the app
• Set the stream rate unit (seconds, hours, days, weeks etc.)
• Edit custom tokens
• Reset UI hints
• Toggle "developer mode"

Design: https://www.figma.com/file/vyI7f996JF8zwhnXwAwXdC/Drips-App-V2?node-id=57%3A1713

Current graphic:

The Splits section displays the current account's splits configuration in a visual representation by default. The user may also switch over to a table list view of their splits. If a lot of splits are present, or some splits are too small to be represented in the visual bar view, it automatically switches to the table list view.

Designs: https://www.figma.com/file/vyI7f996JF8zwhnXwAwXdC/Drips-App-V2?node-id=169%3A5354

design and add the image you see when you share the website (and the app?) online

make sure it works on twitter, linkedin, discord, slack, facebook, telegram.

Appears to be related to bind:this still pointing at the previous step that's being animated away.

The step content awkwardly bleeding over the modal edges while transitioning between steps of different sizes doesn't feel great, but unfortunately setting overflow: hidden on the modal breaks dropdowns. We should hide the overflow only during transitions, but make it visible otherwise.

The link in the dropdown to the settings page is wrong. Currently it goes to /settings, but should go to app/settings