This PR mostly addresses data traceability and allows our app to run in both IPFS mode and Airtable mode. The app is not yet ready from a UI/UX perspective for the way IPFS data is delivered, in the way that an asset in IPFS mode ends up broken into onChainData and offChainData. In Airtable mode this does not happen, as Airtable pull data even faster than the SDK (onChainData), so the asset is 100% completed from the get go. Once we have UI states that cover the gap between the availability times of onChainData and offChainData we can go in and fix the next thing which is:
Resource availability
It can apparently take anywhere from 1 to 4 minutes for a newly uploaded resource to become available in IPFS (namely clouldflare's gateway), this isn't necessarily a massive problem, as it delays asset availability for all users in the same way, in the sense they are all allowed to invest a few minutes later after listing. The problem is the app, which again, is not ready for that. So we need extra clever code to cover this and make sure data is displayed properly and that the user is kept in the loop about what is happening.
Neither of these things I mentioned are hard to fix so we'll get to them. Meanwhile both Airtable and IPFS will be kept updated with asset listings, asset models and operators (not really supported because we have no UI showcasing anything about the Operator right now) and both will hold the same information. Once we determine we can let go of Airtable it'll be trivial to do so.
The React side
Created a new context called AssetsContext just to manage this relation between the SDK, Airtable and IPFS, the output of this context are the assets, in a consumable way, with flags telling its children components whether data is loading, etc.
We are using some of the SDK's events, for when a contribution happens or a new asset listing or a new Asset Model is created, the UI refreshes on its own in those cases. For other types of data updates, such as when an Investor withdraws their profits, I call fetchAsset() on that assetID and reload the onChainData for that asset. This only happens in the user's side and that is fine as that type of data events in other assets don`t matter to the user.
Smaller things:
Created a new fetchAsset function.
Created an IPFSDataManager class to manage all the resources the dApp is required to download from IPFS. Works with callbacks, UI updates as data comes when in IPFS mode. Also we can get clever here with caching mechanisms.
All the mix and match between Airtable and IPFS data and also updated the server with the needed changes to support the new Airtable data structure (Airtable Table here)
File URLs are dynamic, depending on whether Airtable or IPFS mode is on, same for asset images.
Additional Costs section is hidden unless the user added extra costs.
Added a tooltip showing the AM when we add the 8% fee. Here.
handleAssetFavorited has been banished from all the files it was in, in favor of binding that function and its handler to the asset and calling it wherever, a cleaner solution.
Fixed the bug where newly created assets would not be immediately available.
Updated List-asset to include a link to the asset (see - you click it and go to the asset`s own product page in a different tab)
Made the documents section in the Manage Asset Page actually trigger a Metamask transaction for file changes, so that a new IPFS resource representative of that asset listing can be created and saved to ethereum`s DB, before it was only uploading the files to AWS; also made some visual updates to the section. Looking very good.
Fixed the collateral calculator.
New API endpoint at api/airtable/updateAssetListingFiles for when the AM updates the files in an asset listing and /api/airtable/operatorsthat resolves theOperators` table in Airtable.
Replaced a bunch of repeated strings in favor of using constants and functions in /constants/notifications
Updated version to 1.1.0
successfully not successfuly typos
New Documents Section in Manage Asset Page, using the new Figma mockup.
Note:
We don't have any UI for when resources are being uploaded to IPFS, the file size restrictions make this less of a problem but in slower connections users will be left wondering why the app has not yet triggered a transaction.
General description
This PR mostly addresses data traceability and allows our app to run in both IPFS mode and Airtable mode. The app is not yet ready from a UI/UX perspective for the way IPFS data is delivered, in the way that an asset in IPFS mode ends up broken into
onChainDataandoffChainData. In Airtable mode this does not happen, as Airtable pull data even faster than the SDK (onChainData), so the asset is 100% completed from the get go. Once we have UI states that cover the gap between the availability times ofonChainDataandoffChainDatawe can go in and fix the next thing which is:Resource availability
It can apparently take anywhere from 1 to 4 minutes for a newly uploaded resource to become available in IPFS (namely
clouldflare'sgateway), this isn't necessarily a massive problem, as it delays asset availability for all users in the same way, in the sense they are all allowed to invest a few minutes later after listing. The problem is the app, which again, is not ready for that. So we need extra clever code to cover this and make sure data is displayed properly and that the user is kept in the loop about what is happening.Neither of these things I mentioned are hard to fix so we'll get to them. Meanwhile both Airtable and IPFS will be kept updated with asset listings, asset models and operators (not really supported because we have no UI showcasing anything about the Operator right now) and both will hold the same information. Once we determine we can let go of Airtable it'll be trivial to do so.
The React side
Created a new context called
AssetsContextjust to manage this relation between the SDK, Airtable and IPFS, the output of this context are the assets, in a consumable way, with flags telling its children components whether data is loading, etc.We are using some of the SDK's events, for when a contribution happens or a new asset listing or a new
Asset Modelis created, the UI refreshes on its own in those cases. For other types of data updates, such as when anInvestorwithdraws their profits, I callfetchAsset()on thatassetIDand reload theonChainDatafor that asset. This only happens in the user's side and that is fine as that type of data events in other assets don`t matter to the user.Smaller things:
fetchAssetfunction.IPFSDataManagerclass to manage all the resources the dApp is required to download from IPFS. Works with callbacks, UI updates as data comes when in IPFS mode. Also we can get clever here with caching mechanisms.Additional Costssection is hidden unless the user added extra costs.handleAssetFavoritedhas been banished from all the files it was in, in favor of binding that function and its handler to the asset and calling it wherever, a cleaner solution.api/airtable/updateAssetListingFilesfor when the AM updates the files in an asset listing and /api/airtable/operatorsthat resolves theOperators` table in Airtable./constants/notificationsNote:
We don't have any UI for when resources are being uploaded to IPFS, the file size restrictions make this less of a problem but in slower connections users will be left wondering why the app has not yet triggered a transaction.