Added classification vis & settings, switched to vue-cli, massiv…#145
Added classification vis & settings, switched to vue-cli, massiv…#145
Conversation
|
There's a lot of nice changes here, but one primary thing missing here is the ability to do make your own tags and save them. Could we focus on taking in the underlying aw-server changes here, then take in these aw-webui changes and then disable the view by default until we have solved that? I would hate to see this PR stagnate and need huge rebases in the future. |
| title_events = limit_events(title_events, ${titlecount}); | ||
| duration = sum_durations(events); | ||
| RETURN = {"app_events": app_events, "title_events": title_events, "app_chunks": app_chunks, "duration": duration};`; | ||
| RETURN = {"app_events": app_events, "title_events": title_events, "cat_events": cat_events, "app_chunks": app_chunks, "duration": duration};`; |
There was a problem hiding this comment.
As we have learned from earlier when we didn't have proper queries, sending all events to the web-ui and computing it there is not scalable for more than a days worth of data.
You should instead for example utilize the merge_events_by_keys for categories and write some new transform in the server for tags.
There was a problem hiding this comment.
But I am using merge_events_by_keys? I'm basically only sending one event per category in the cat_events.
We should not use browser storage for this, we should have an API in the server to save this. We don't want all tags to be forgotten if we switch to a different browser. |
Agreed, but just as with the next-day-start setting, I'm saying we could use browser storage until we have such a key/value store in aw-server for stuff like this. |
As I said, I think it'll be perfectly fine to use local storage until we have a way to store settings in aw-server. I also want to refactor ActivityDaily.vue (using nested routes for the tabs) which I'll probably do in this PR. If I end up doing that I'll probably end up moving this stuff to a new tab with a "work in progress" disclaimer, which should prevent stagnation of this PR. |
Alright, but could we move it out to a separate view so it's clear that it's WIP? I don't want to add WIP features onto the primary view both because it gets cluttered but also because we want it to be very clear that it's WIP.
I thought the plan was to refactor everything into the Summary view to then remove the daily view? Please don't waste time working on improving the daily view as that will just become duplicate work. |
I did not know this? What makes the Summary view such a great replacement? I really don't see it. Anyway, before you replied I had already refactored the daily view massively, which should make it much easier to work with. (see the latest commit) |
Mostly because of the fact that if you implement something once you get it for free for all other time ranges. |
Now that you have splitted out each section to its own file though that idea is probably moot as now each section is modular. Nice |
|
Next time though please don't do massive linting like this in the same PR as actual code, it's really hard to read. |
src/views/Settings.vue
Outdated
| this.classes.push({name: "New class", re: "FILL ME"}) | ||
| }, | ||
| saveClasses: function() { | ||
| saveClasses(this.classes); |
There was a problem hiding this comment.
We should validate the regular expression before saving them. JS has built in re if i recall correctly.
There was a problem hiding this comment.
The entire thing needs validation. This is probably not the final version of the UI anyway, but it works.
Yeah, sorry about that.
It will be even nicer when I get the whole thing into vuex and refactor the query builder. |
… vuex, added support for typescript, added tests with jest, and more I probably forgot about
|
@johan-bjareholt It would be nice to have another review. The only thing missing is the ability to edit the categories/rules. |
| queryOptions: { | ||
| aw_client: this.$aw, | ||
| date: moment().format('YYYY-MM-DD'), | ||
| host: 'erb-laptop2-arch', |
There was a problem hiding this comment.
If you want this to go into master you should at least stop hardcoding this.
Just adding a text field or something as an input though should be good enough as i assume it's made to be a rough tool rather than for user debugging.
There was a problem hiding this comment.
Ah right, I forgot. Will do.
|
This pull request introduces 1 alert and fixes 1 when merging 663f61c into c29c1cc - view on LGTM.com new alerts:
fixed alerts:
|
|
This pull request introduces 1 alert and fixes 1 when merging a60ed2b into c29c1cc - view on LGTM.com new alerts:
fixed alerts:
|
|
This pull request introduces 1 alert and fixes 1 when merging 3a5a5c6 into c29c1cc - view on LGTM.com new alerts:
fixed alerts:
|
|
This pull request introduces 1 alert and fixes 1 when merging 2b8bcbd into c51e5f4 - view on LGTM.com new alerts:
fixed alerts:
|
|
This pull request introduces 1 alert and fixes 1 when merging 53b5792 into c51e5f4 - view on LGTM.com new alerts:
fixed alerts:
|
|
This pull request introduces 1 alert and fixes 1 when merging 3ac9190 into c51e5f4 - view on LGTM.com new alerts:
fixed alerts:
|
be528d5 to
35f26bf
Compare
|
This pull request introduces 1 alert and fixes 2 when merging c0a66d4 into c51e5f4 - view on LGTM.com new alerts:
fixed alerts:
|

Todo
Now
/summaryappended)$route.params.async/await-ed.
(adding/removing categories doesn't work right now, only editing)After
eslint --fixon entire project in new PR that will be immediately merged. (Done in Lint it all #150)Later (uncompleted moved to #151)
Depends on
How it looks (for now)