Closed VoodooWonderBot closed 5 months ago
@VoodooWonderBot Nice work, I agree @Potato-Man114, I like the idea of them being in the same app at different routes.
One thing I will add (and maybe we can figure this out as part of https://github.com/users/jak103/projects/6/views/1?pane=issue&itemId=66292450) is that since our current vue installation on main was created before we were requested to use quasar, it complicates the quasar install a bit.
We will either need to install and integrate the quasar vite plugin with our current vue instance, or create a new quasar vue app using their CLI tools, and migrate the existing frontend stuff over. I personally think the latter option is preferable, since we could then utilize all the quasar CLI features as intended.
I don't think it would be too bad since we only have a few frontend pages at the moment. I also messed around with the standalone vite plugin for a while and ran into a few issues, but using the quasar CLI to start fresh just worked out of the box. Anyway maybe something we can think about.
After a quick look, I've got two suggestions:
Following the principle of DRY, the entryboard must be either
1. a page in the powerscore web app, or 2. a separate application
not both. Personally, I prefer option 1. Therefore, unless there is some preventing limitation, please incorporate the changes from the
powerscore-entryboard
directory into thefrontend
directory.Second, I like that the page updates automatically every now and then. Can you set the page to request the information when it is loaded, rather than waiting the first 10 seconds?
I'll look closer at the code tomorrow and add any recommendations I have then.
For your first point, it's not supposed to be in our repo at all I believe. That's just where it was when I edited it, as I mentioned in the request text and the comments it needs to make its way to the main repo if admins are going to be assigning teams.
For your second point, that's kind of a bug with how I implemented it...it does the initial GET when the page starts up so it has the data but in those few miliseconds it takes to get the data the page is already loaded and needs to hit that next ten second refresh before it shows. I could make the refresh interval sooner if I need to change things for the stuff Clark brought up.
@VoodooWonderBot Nice work, I agree @Potato-Man114, I like the idea of them being in the same app at different routes.
One thing I will add (and maybe we can figure this out as part of https://github.com/users/jak103/projects/6/views/1?pane=issue&itemId=66292450) is that since our current vue installation on main was created before we were requested to use quasar, it complicates the quasar install a bit.
We will either need to install and integrate the quasar vite plugin with our current vue instance, or create a new quasar vue app using their CLI tools, and migrate the existing frontend stuff over. I personally think the latter option is preferable, since we could then utilize all the quasar CLI features as intended.
I don't think it would be too bad since we only have a few frontend pages at the moment. I also messed around with the standalone vite plugin for a while and ran into a few issues, but using the quasar CLI to start fresh just worked out of the box. Anyway maybe something we can think about.
@clickclackclark @Potato-Man114 @jebidiah252 should I take care of this now or should I work on other stuff? Do we need more manpower on anything else?
@VoodooWonderBot @Potato-Man114 @jebidiah252 I've already created a new quasar-cli vue app in a separate directory on my local branch for the iPad frontend so I was thinking once I'm done updating and moving that over, I can get it pushed. Then we can have separate issues for migrating the other pages over if we end up wanting to go that route?
From what I'm looking at, it seems like we're writing the same thing in two different places. Like @Potato-Man114 stated earlier, this violates DRY (don't repeat yourself) and could be consolidated into a single place. I like the idea of this being it's own directory within this repo (powerscore-entryboard) to help with CI/CD builds down the road. Just some food for thought though.
With the context of https://github.com/jak103/powerscore/issues/24, I agree that it should be in the powerscore-entryboard
directory instead of the frontend/src
directory.
From what I'm looking at, it seems like we're writing the same thing in two different places. Like @Potato-Man114 stated earlier, this violates DRY (don't repeat yourself) and could be consolidated into a single place. I like the idea of this being it's own directory within this repo (powerscore-entryboard) to help with CI/CD builds down the road. Just some food for thought though.
I can move the files over, I just don't want the headache of making them work in the new folder when that particular app needs to find a home outside of this repo anyway. Or I could delete it, now that I know how to do it I can have a new version up as quickly as I can learn quasar.
@jebidiah252 @Potato-Man114 @clickclackclark I can start on doing this with quasar instead if we don't need manpower elsewhere.
Let me know if I need to mess with anything else. I don't have merge permissions so someone else will have to hit it.
Made the entryboard a standalone vue app that automagically pulls the assignments from an endpoint. Nothing more, nothing less. I tried to add a TODO wherever I thought it was lacking.
When it can't find the endpoint (or is just starting up):
When it gets data (it asks for data every 10 seconds):
(I only put 4 teams on the endpoint, that's why the last one is still waiting)
I also changed the one that Matthew originally made to grab teams from the same endpoint so that they can be assigned by a theoretical admin. This will eventually need to be in the powerplay app instead, but here is the lightly modified interface (still works the same way):
The refresh button is just in case it needs to grab teams again.
The README in powerscore-entryboard has instructions for testing with dummy data
Please ask questions, I definitely messed something up.