computablelabs / ffa-frontend Goto Github PK

Let's have Travis consider linter failures as a build error.

Assuming that an upload succeeds a candidate will be created. This creates a number of getters that are necessary for showing the user the state of said candidate

• Listing contract
  • getListing
  • isListing
• Voting contract
  • isCandidate
  • getCandidate

We'll break out vote into a separate ticket so it may be that all the candidate issues belong there...

Identify all Vue components and Vuex modules that need a refactor:

We need to flag every class that needs to have methods pulled out into a separate pure function container class, basically just a module with funs.

So that's anything in a module that isn't a: Vuex state attribute, Vuex mutation, Vuex action mutation, Vuex getter.

Put the list here in the convo of the issue.

References #67

Re #5 bullet 1

It is irrelevant that .../new may redirect to here. We may choose to not do that...

anyway

see #10 pertaining to listing vs candidate

If it is decided that .../listing/hash shows the candidate (the listing as candidate:true or something).

@thirtyaughtsix in my opinion this "page" is where the dapp can query for the state of the listing/candidate in question. There are a couple of ways to do this

• simply ask if the given hash is a listing. we know this will be false until it is voted in.
• the same can be asked if this hash is a candidate. again see #10
• in #9 the client will recieve back a transactionHash this could be kept and then used to query the blockchain with. If this is the case, more questions arise about the keeping of these beyond the page lifecycle

Subject says all...

Put in a preliminary implementation for at least the flash messages.

Both upload and list have two processing steps. Status should reflect these. We probably want to replace the percentage circle thing with a spinner but we'll that up to Reid.

The foo.all type endpoints are going to have to use getPastEvents and grep those logs for Application. Build the plumbing to fetch and parse this data so that UI/UX can be built after.

See #11

Let's move StartListingButton from FileMetadata to the ListDrawer.

That means ListDrawer will need two states:

1. StartListingButton state
2. Processing state

The question is gonna be should this be handled in ListDrawer (I believe that's correct) or by fiddling with the Vue slot in Drawer that ListDrawer occupies.

What protocol methods do we care about for the the upload? If we are focused solely on the uploaded asset itself likely this is just

• listingContract.list

Need to figure out how we want to generate the listingHash and what exactly it is we are hashing

• do we let the client provide some "original string" then hash that?
• does the client want a means to remember this to prevent the user from not remembering what their own listingHash is...
• if yes on the above is it the client's responsibility solely or should it involve the datatrust?

See #8

The FileUploader should subclass a generic DatatrustClient class.

Use the list from #73 and refactor each Vue component. One component -> one PR.

New funs should be pure so they can be static. Let's create a new top level folder called @/functionModules. Component function modules probably belong in @/functionModules/components while Vuex modules probably belong in @/functionModules/vuexModules/.

Don't forget to add specs!

A user can support a market using a web browser and Metamask

Assume:

• User has Metamask installed and set up with at least one private key/address
• Metamask address is funded with appropriate token (skynet, testnet, or Eth)

User can then:

1. Navigate to https://.../support
2. See current support price (via Reserve.getSupportPrice)
3. Enter how much in Eth they want to invest
4. Click deposit button
5. Use Matamask popup to sign 1st transaction (EtherToken.deposit)
6. See a message (mining...) indicating transaction is being mined
7. After 1st txn mined, see and press approve button
8. Use Matamask popup to sign 2nd transaction (EtherToken.approve)
9. See a message (mining...) indicating transaction is being mined
10. After 2nd txn mined, see and press support button
11. Use Matamask popup to sign 3rd transaction (Reserve.support)
12. See a message (mining...) indicating transaction is being mined
13. After 3rd txn mined, see number of MarketToken just minted (via Reserve.Supported event)

This is an agile style "vertical slice" to force us to integrate browser + metamask + protocol into a functioning prototype. It deliberately excludes features that we will probably want for a public launch, including CSS.

A user can create a listing candidate using a browser + Metamask

Master ticket complete when:

Assume:

• User has Metamask installed and set up with at least one private key/address

User can then:

1. Navigate to https://.../new which creates a listing hash and redirects to https://.../listing/<listhash>
2. See an empty listing
3. Drag a file onto the page to start the upload process
4. See the progress of the upload while...
5. Entering listing details including title, description, tags, license
6. Click List button once file upload is complete
7. Use Metamask popup to sign transaction (Listing.list)
8. See listing details (as they will appear when viewing the listing) and a message saying that mining is happening. User can close browser and come back to see progress at this point.
9. Once mining is complete, message now says voting is happening
10. Once voted in, listing appears as it will for any user. If listing is rejected, message says listing has been rejected.

This will tie directly to the Web3 card Rob will submit shortly.

Essentially the Listing HOC from computable.js should be encapsulated in the Web3 vuex module.

There is a skeleton Listing class under models/protocol. Probably ok for it to stay there but the pattern of how the eth_sendtransaction methods are called needs a rethink based on what we know about MetaMask.

Referencing #5 bullet 1

• router entry
• vue component(s)
• what is the exact URL?
• other?

See #8

The ListingCreator should subclass a generic ProtocolClient class.

...and move the title in use logic to the module.

Follow the pattern from #75, #76 and refactor the protocol integration under @/models/protocol out into @/functionModules/protocol

Re: #5 bullet 1 and bullet 6

• How is the listing hash generated?
• How do we associate that listing hash with user's ETH account
• do we plan to keep a cache of them?
• if so where? (datatrust/client...)
• how does frontend want to handle notification of transaction completion/failure

Looks like we're missing license:

            if not request.form.get(item):
                api.abort(400, (constants.MISSING_PAYLOAD_DATA % item))```

Should also remove any extraneous params we're sending like `originalFilename`.

How do we want to handle sass per component?

See #8.

Virtual route: /list

Dependencies: #13, #14

Use this component to bootstrap tests.

Need to change css to prevent FIle Uploader from creeping down with new rows of tags.

The most basic - is there an account ready to be used?

• Design in Sketch
• Front end implementation (approximate UI)
• UI matched to design

A user can buy and then download a listing’s data using a browser + Metamask

Assume:

• User has Metamask installed and set up with at least one private key/address
• User has address funded with some Eth

User can then:

1. Navigate to https://.../listing/<hash> to see the listing’s details
2. Click Buy to start buying the listing (or Download if already bought)
3. Click through steps to wrap Eth, approve spending of WETH, buy the listing
4. See and then click a download button to view/download listing’s data.

Notes

• It should be possible to go through a simple, continuous flow from Eth to downloaded data, wrapping the ETH and approving spending along the way. In this flow the user needs to click to move the process along, but doesn’t need to decided how much ETH to wrap or approve, it’s whatever is needed to pay for the listing.
• Engaged users can choose to wrap a user-specified amount of ETH and approve a user-specified amount of WETH for bulk buying of listings, but that will be part of a different, dedicated flow.
• If a user clicks Buy but already has enough WETH wrapped or approved, then the progress component should render with these steps already complete. This may happen if the user started to buy, left the page while a transaction was being mined, then and came back to continue; or it may happen if the user has bulk wrapped ETH to WETH already.
• If a user has bought the listing in the past, then it renders with a Download option instead of Buy.

Create a Tab component and then wire it into FileUploader. Apparently there isn't any UI for this.

1. There should be a text field for input. We'll may/mayn't add auto-complete later.

2. Enter in the text field adds a new tag rendered somewhat pill like in a div below the text field. Pill should render a delete x on hover - use a font awesome icon for this.

3. Probably need to add an Add button next to the text field for people who don't understand how the return key works.

The more interesting questions are around what the tagging vuex module looks like and how that gets wired into UploadModule.

The title field should default to the filename when files are dropped in FileUploader. This was working before.

Can we use MM to sign/approve/send etc...?

github wasn't able to auto-generate a repair PR :(

A lot of stuff can just be moved to a Constants or Strings file. I like to use string interpolation so that might be worth thinking about (course i can just do
somePath = `${Constants.foo}/${Constants.bar}` .

We really shouldn't spend a lot of time on this.

Add an option in Flash like unique: boolean and prevent unique Flashes with the same messages from being added to the module.

Gah. It's requiring semicolons...

Once an upload has been completed and a listing applied for it will be time to care about voting

SETTER

• voting.vote

GETTERS

• voting.isCandidate
• voting.getCandidate
• voting.pollClosed
  *voting.didPass

others?

The foo.all type endpoints are going to have to use getPastEvents and grep those logs for Application. Build the plumbing to fetch and parse this data so that UI/UX can be built after.

See #10

Identify all Vue components and Vuex modules that need a refactor:

We need to flag every class that needs to have methods pulled out into a separate pure function container class, basically just a module with funs.

So that's anything in a component that isn't a: Vue property, Vue data, Vue getter, Vue named event handler.

Put the list here in the convo of the issue.

References #67

Use the list from #74 and refactor each Vuex module. One component -> one PR.

New funs should be pure so they can be static. Let's create a new top level folder called @/functionModules. Component function modules probably belong in @/functionModules/components while Vuex modules probably belong in @/functionModules/vuexModules/.

Use the list from #73 and refactor each Vue component. One component -> one PR.

New funs should be pure so they can be static. Let's create a new top level folder called @/functionModules. Component function modules probably belong in @/functionModules/components while Vuex modules probably belong in @/functionModules/vuexModules/.

Don't forget to add specs!

UI/UX for the start listing button.

There is an important distinction to make about candidates vs listings

• any listing candidate is not an actual listing until it is voted "in"
• any listing candidate is simply a candidate until it is voted "in"

Other candidates do exist:

• reparam
• challenge

Therefore a UI/UX decision must be made. Does the route ../candidate/hash and the route .../listing/hash show the same thing? Or do we choose to show nothing on the listing/hash for listings which are still in their applicant phase?

NOTE: Other candidates do not have the permanence that listings do. A challenge or reparam simply vanish when voting is done...

Create a new Web3Module vuex module. We'll quarantine Web3 here and also encapsulate the protocol stuff here as well.

First things first, we need to include a Web3 into the project. It needs to be exactly version beta-37.

One thing to keep in mind (and it has relevance to the class/no-class discussion - and no I ain't talking about the Kardashians): something weird happens in certain contexts whereby the type of the VuexModule isn't what you expect it to be. Rather than being an instance of your fancy custom subclass of VuexModule it appeaers to be a decorated version of state. That means that most of your expectations about this.whatever are wrong.

The tl;dr is that we need to use external classes to encapsulate logic we want to externalize from methods in any VuexModule. This probably drives OO purists nuts. Good.

Front end shootout: React, Vue, Angular.

• CSS organization / framework (style components, bulma, etc)
• UI components (material design, something else)
• How to serve html/css/JS (nginx, node, etc)
  ^ added by reidw, Ken not sure if this is same or different than your headline for the card. Feel free to break this up.