API features for UX improvement

[masonchain]

As we're moving further along on the front end, some things are necessary to iterate on in the backend to provide better UX.

More might come along but these are the main items I can currently think of. Feel free to make any changes at will and just let me know so I can implement.

• [x] Proposals

  • [x] Voting Percentages (pref. as array [yes%, no%, abstain%, unaccounted%])
    • Not sure a better name for unaccounted -- basically just votes not used for the 3 options.
  • [x] Implement list view for getting all proposals
  • [x] Sorting:
    • Feel free to implement others but this is what I got
    • [x] Newest
    • [x] Oldest
    • [x] Most Popular
    • [x] Least Popular
  • [x] Filtering
    • [x] UX tags
    • [x] Open
    • [x] In Progress
    • [x] Concluded

• [x] Voting

  • You may have already implemented this so feel free to ignore if so, just hadn't checked your progress on the voting end recently.
  • [x] GET for current $RUNNER balance of account
  • [x] GET for if they have voted on proposal pk
  • [x] POST for vote containing proposal pk and selection

• [x] System Message

  • The message above the header.
  • Should probably be in the database so we can update it on the fly.
  • [x] GET request for current active message
  • [x] Properties:
    • Message
    • Link to
    • Active

• [x] Email List

  • [x] Need somewhere to post email addresses from the landing page
  • Currently have code doing simple cleaning of the input but if you think it might be a good idea to further check this then feel free.
  • function isValidEmail(email) { return /\S+@\S+\.\S+/.test(email); }
  • I don't have any fancy requests and haven't implemented anything around this yet so really just need the url to the view and if any token is needed.

• [ ] Roadmap Items/Tasks

  • This is probably a good idea so it can update based live based on what we're doing.
  • [ ] GET list of all items with the version being the keys and items/tasks being their children
  • [ ] Properties of parent:
    • Version
    • Description
    • children array
  • [ ] Properties of children:
    • Title
    • Description
    • Status (In progress, Upcoming, Completed)
    • Link to wherever we're storing the tasks (github or other proj mgmt.)

[nftchance]

Unaccounted for will not be included. We aren't chasing quorum.

[nftchance]

Roadmap won't be in the API. I will figure out what the injest pattern is.

[nftchance]

Balance of user is returned from raw UserSerializer rather than being another call that is needed to be made.

(We will likely be adding a little button to the dashboard template that shows the balance at all times to gamify the experience of them making money + $run)

[nftchance]

Balance of user is returned from raw UserSerializer rather than being another call that is needed to be made.

(We will likely be adding a little button to the dashboard template that shows the balance at all times to gamify the experience of them making money + $run)

With this implementation, when a user is not logged in we will just show a button that prompts them logging in before being able to vote so that there is never a case where you "need" the balance before they are logged in.

[nftchance]

System messages are built upon:

    title = models.CharField(max_length=100)
    link_text = models.CharField(max_length=100)
    link_url = models.CharField(max_length=100)
    external = models.BooleanField(default=False)

    expired_at = models.DateTimeField(null=True, blank=True)

    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

When querying the list:

^system/broadcast/$ [name='broadcast-list']

Only Broadcast messages that haven't expired will show. Right now, Broadcast messages can only be created within the admin section and can have an infinite run-time while others can have an expiration time set.

[nftchance]

Multiple messages can be returned at once. In which case, they should alternate between one another.

[nftchance]

The email list will have to wait until the primary API architecture has been merged.

[nftchance]

Can order the order proposal list by created_at and votes_total

To get this in a URL it would be: https://localhost:8000/proposal/?order_by=-created_at

[nftchance]

Tried implementing the most popular, but not only does it not make sense to have as an option, it is an absolute pain to add. Instead, you can sort by any field. So instead of most popular and least popular, we will replace it with 'time most remaining' and 'time last remaining.'

Along with this I went ahead and added searching to the fields of title and description.

Finally, tossed in field value checking of: id, title, description, approved

Last thing to do here is to make sure that we can filter by status.

[nftchance]

Was closed by the linked PR.

[nftchance]

Waitlist has been taken care of. You can now find the docs for all API endpoints at:

HTTP://localhost:8000/docs/

[nftchance]

I am unsure of the best way to implement the schema for the roadmap. On the one hand, it could be implemented in the API, which is laborious and like storing the same data in 4 different places. I am not a fan of this approach however if you zoom out then realistically, the workflow is this no matter what you do.

There does exist a way to just use the REST API from GitHub to get the project details. However, that still leaves many things to be desired and a workflow that is again less than ideal. Why? Because you have to have an authentication token...

This brings us to the point that I think the roadmap best serves by being static and more generalized than first planned. Kind of lame but not worth spending a lot of time on when we will have many changes in the roadmap. So, I guess it being bluntly straightforward is best anyways.

[nftchance]

Roadmap will be static on the front-end. No real reason to make it truly dynamic.