artsy / hack8-next-prediction

NextJS Typescript Boilerplate

Bootstrap a developer-friendly NextJS app configured with:

• Typescript
• Linting with ESLint
• Formatting with Prettier
• Linting, typechecking and formatting on by default using husky for commit hooks
• Testing with Jest and react-testing-library

Deploy your own

Deploy the example using Vercel:

How to use

Execute create-next-app with npm or Yarn to bootstrap the example:

npx create-next-app --example with-typescript-eslint-jest with-typescript-eslint-jest-app
# or
yarn create next-app --example with-typescript-eslint-jest with-typescript-eslint-jest-app

Deploy it to the cloud with Vercel (Documentation).

hack8-next-prediction's Issues

Auction page with sale + artwork data loaded from metaphysics

Related to #5 - just coordinate with whoever is doing that
A page showing the current, live state of an auction:

A/C:

• an /auction/:id route (eg a page from src/pages/auction/[id].tsx)
• I think the id param above should work with either a sale slug or id because our metaphysics + gravity queries will ultimately accept either.
• see the documentation for getInitialProps and getStaticProps - I think we may be able to leverage incremental site generation for faster load times on the metaphysics side
• present the artworks in some simple way on the page

User can select a lot and see more detailed state data

Let's organize data so a user can select a lot and see more detailed data about it.
followup to #5

AC

User can click a lot from the list and see expanded data about it. This might be a good place to dump a JSON.stringified bunch of data about the artwork.

Front page: auctions list

The front page should host a list of active sales, visible to an unauthenticated user. See examples of this in force, prediction and eigen.

AC

A list of sales similar to what we see at https://live-staging.artsy.net - only palette-powered. Clicking on one links to its page at /auction/:slug (see #2). Don't worry about filtering on whether the sale is live at this point.

Identity a user's watched lots as we do their lot standings

Let's show a user's watched lots.

AC

• A user who has watched a lot in gravity (same as saving/'liking' an artwork) can see those lots identified on the sale page list of artworks. maybe there is a heart or an eyeball emoji.

Notes

This might require a metaphysics query to get these sale artwork ids. Talk to @erikdstock - he has already been looking into this.

Websocket connection to causality

Let's try to get live data from causality 😬
Blocked by #3

AC

A websocket connection to causality's graphql schema keeps the sale page up to date as data changes.

Notes

This is totally out there but would be huge to unlock - even a tiny bit. We want graphql subscriptions about lot updates. Sangria is the name of our graphql library and some of its documentation on the subject begins around here

Causality Graphql connection

With our auction page loading all artworks in a sale, we now want to query the auction state from causality's graphQL api.

AC

Fill in the list of artworks with their current auction state from causality. We don't need to fit the whole state in every list item.

Notes

We have two choices for accessing causality:

• through metaphysics' stitched causality schema, though we would have to whitelist this field
• through causality's own graphql api. I'm in favor of this since it seems simpler for a future websocket graphql subscription to work with only one graphql api.

Assuming we query causality directly:
This will require fetching a special causality jwt via metaphysics, and then we should be able to query something like sale(id: id) { lots { ... } }. We won't have all data currently available to causality, so let's just take what makes sense.

A later stretch goal will be to figure out websocket subscriptions. For now the examples in the metaphysics hook using swr might be a good starting point.

Group sales index by their place in the sale lifecycle.

AC

Group sales on our main page by their time. One recent approach to this is with our

Notes

One example approach for some of our 'timely' definitions would be our [TimelySale]
(https://github.com/artsy/eigen/blob/bcf21d57bfed8af78a04467263df579975f1c5ce/src/lib/Scenes/MyBids/helpers/timely.ts#L21) class in eigen. It relies on gravity backed properties status, liveStartAt and endAt, while endedAt (not used there) indicates that a sale has closed.

Highlight lots a user is participating in on the sale page

This feature doesn't currently exist in prediction.

AC

A visual indication in the list of lots indicating the user has a bid, whether they are winning, whatever is useful and looks nice.

• the layout portion could be split into a separate ticket, so this would just be getting and logging the json from the api. Use your judgement.

Notes

• This will be another request that comes after the initial/static props. We basically want to request the user's current lot standings and display that data in line with the lots - see eigen's MyBids code for an idea of what this query might look like.
• Because we are already talking to causality directly (in #3), we could ask for this directly from causality (Query.lotStandingConnection(userId: ID!) rather than metaphysics Me.auctionsLotStandingConnection). How we do it is up to whoever picks it up.
• the lotStandingConnection does not filter for sale ids, but if anyone would like to try to pair on adding that as an optional arg we can do it.

Live auction observer layout

A skeleton layout for the sale interface.
Blocked by #2.

AC

• A prediction-like, palette-based interface, things to make prediction look nice when the data is available.
  This should be on an /auction/:id route (eg a page from src/pages/auction/[id].tsx)