Synopsis:

There are a couple different ways to design an app but most are centered around the way the data is stored and accessed. This is the reason why going from a one-directional marketplace to a bi-directional marketplace was difficult: everything built "on top" of the data had to change as well.

Goals

Streamline our development and product planning processes.

Goal 1 - finalize data model based on our desired functionality

It took ~3 weeks of intense work to change to a bidirectional marketplace and another week to make it work well (debugging, refactoring, etc). I think it was:

worth the changes and
we're more or less finalized on this data model
but we should try to make these bigger decisions less frequently NOTE: it's like moving a house's foundation after it's been built.

NOTE: see below for a technical account of what it took (click for link)

So, to carry on with the house foundation metaphor: I think it'd be good to confirm a long term (not permanent) data model that can help us best confirm the most important assumptions we're trying to test with the market and users.

Goal 2 - decide on higher level design layouts (UI/UX)

I apologize if we already covered this in the wireframe but I'm having trouble deciding how to organize a user's profile offering. I propose we group them by profile types or offer types:

Grouped by profile type:

PRODUCTION COMPANY:
  responding offers
    associated exchange requests
  requesting offers
    associated exchange requests

MAKEUP ARTIST
  responding offers
    associated exchange requests
  requesting offers
    associated exchange requests

HAIR:
  responding offers
    associated exchange requests
  requesting offers
    associated exchange requests

Grouped by offer type (this is what we have currently):

RESPONDING OFFERS:
  production company offers
    associated exchange requests

  makeup artist offers
    associated exchange requests

  hair offers
    associated exchange requests


REQUESTION OFFERS:
  production company offers
    associated exchange requests

  makeup artist offers
    associated exchange requests

  hair offers
    associated exchange requests

((click for note on layout)[https://gist.github.com/eternal44/dd0fdc7c085ef53f95ced3ccc5cbe545#existing-offer-er-association-layout])

Notes

Note #1 - Technical Kill List:

This is a quick list of the things I needed to do to create & implement data changes for the bi-directional marketplace on the FE, BE, and DB.

IT:

debugging a shitty wifi connection configure WIFI driver with and connect with an WPA network lol - failed and ended up buying a cheap laptop to keep working

Database:

DB schema model PostgreSQL

Backend:

translate DB schema model to SQL DB migrations Rails - ActiveRecord
model data models (differeint from schema model) Rails - ActiveRecord
write plain ol' SQL where data model won't suffice PSQL
test data mdoels RSpec
write routes Rails - ApplicationController
write controller actions Rails - ActiveSupport

Backend <-> Frontend "Glue":

give and receive traffick to the FE react-rails(server-side rendering webpack compiler to allow rails to SSR React code

PERSONAL NOTE: this is where i picked up from when we started over. i was using CSR react code with unauthenticated requests going back and forth and still needed to: - securly pass requests between the FE and the BE - figure out how to make React-Router work with Rails' router - all on top of learning React and Rails? fahgeeet abowdiiiit

Frontend:

make responses from the FE use forms or axios PERSONAL NOTE: forms only pass GET and POST requests. no PUT :(
learn and implement DOM manipulation through React state change to re-render all of the child compnents
- this is required for the 'bones' that makeup the FE
tried adding CypressJS and couldn't get it to run so i abandonned FE testing for now for manual tests.
- i'll write the FE tests after we set the bones because i have to learn a new testing framework (EnzymeJS)
basic layout design with HTML/JSX, CSS with React-Bootstraop so i can "sketch" the shape of the data into components the way i need
brush up on & configure basic workflow for FE development (devtools, redux logger)

Note #2 - Existing Offer-ER association layout:

You'll notice a few of these terms are familiar. We already have the offers and their associated exchange requests

eternal44/gist:dd0fdc7c085ef53f95ced3ccc5cbe545