-
-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(ui): results of vue create ui using vue2 defaults #1122
Conversation
@hairmare Is there a way I can assist? I would really like to learn Vue and Javascript. |
Most changes you make to the
|
@hairmare Just wanted to suggest we step down to Vue 2 if we still plan on using Vuetify. I've gotten a lot of errors trying to add Vuetify to the Vue 3 setup; apparently this is a known issue: vuetifyjs/vue-cli-plugins#140, https://vuetifyjs.com/en/introduction/roadmap/. |
I encountered that as well and downgraded Vue2, it's not only Vuetify but also VueI18n that is't ready yet. In this PR I've worked on Vuetify since it's what I know, that does't mean I'm not ready to replace it with Bulma (which I dont know enough about, yet). I want to get (jest-based) Unit-Testing up and running next, and I'll contribute to the discussion regarding Vuetify vs. Bulma vs. ... once I have that done in a PoC fashion based on the ExternalDataMenuButton in the PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should also remove any assets from this while I implement the changes I just self-reviewed.
@@ -0,0 +1,28 @@ | |||
<template> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a comment to clarify that this is just a demo that I expect to be replaced b4 we use this.
import Vue from 'vue' | ||
import Vuetify from 'vuetify' | ||
|
||
import ExportDataButtonMenu from '../../src/components/ExportDataButtonMenu.vue'; | ||
|
||
describe('ExportDataButtonMenu.vue', () => { | ||
const localVue = createLocalVue() | ||
let vuetify | ||
|
||
beforeEach(() => { | ||
vuetify = new Vuetify() | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Figure out if this can be abstracted so we don't have to add it in each test.
export default { | ||
name: 'ExportDataButtonMenu', | ||
props: { | ||
data: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider this:
data: String, | |
data: Object, |
@@ -0,0 +1,14 @@ | |||
module.exports = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can/should I move this to package.json?
Most of what is in this PR is scaffolding... The real MVP is in Those files show how you can add a component ( |
This issue has been automatically marked as stale because it has not had activity in the last 5 months. It will be closed if no activity occurs in the next month. |
@hairmare I've added a bit of work to your branch. How should I fold my commits into your fork? |
@zklosko you should be able to push to the branch because the PR is open |
Maybe I checked it out incorrectly. VSCode says I don't have permission to push to radiorabe/libretime on Github.
|
It may be a maintainer/contributor permission difference... @hairmare are you still working on this or shall we take it over? I'd like to get working on this soon |
@paddatrapper Would it be okay if we switched to a Vue framework like Nuxt JS? There seems to be a lot of boilerplate that could easily make the project complicated. |
@zklosko I have no strong feeling either way. Server-side rendering is nice for some of the things we are doing. The requirements I see are:
|
@paddatrapper I take back my request for Nuxt, but I still feel unclear as to our goals for the rewrite. Decoupling the backend means we have to put more focus into the API, but we could push ourselves to keep an eye on the API nevertheless. We could pre-render each page on the server (especially helpful for i18n), but that would require an additional server process to keep running. We would also need an additional Docker container in a Docker setup (UI + API + DB + Python + RabbitMQ + Liquidsoap + Icecast + Nginx/Caddy); it seems we are adding in additional points of failure without it greatly benefiting us. An idea before was to statically generate the app and then serve it from Django, is that still what we're aiming for? |
A vue.js app wouldn't need an additional server - the js is generated at build time and served by the webserver. So the apache process already serving the PHP, serves the js. I agree with you that we don't want yet another process running and there is a fair amount of things that wouldn't be able to be rendered server side (live DJ interface, uploading, scheduling, etc). We're going to end up with a lot of client-side js either way |
That almost sounds like what we had before - templating in PHP with functionality in JS. Since Django already gives us i18n support and login auth, why not use templating and middleware in Django with component-based functionality in Vue.js? We can still minify and bundle the JS but the UI would be so much faster that way instead of entirely building it client-side. I think we can still use Vuetify as a UI framework. There's arguably a lot that we don't need JS for:
|
I would like to move to Vite from Webpack, because it's a lot faster, simpler, and still works with i18n generation, if that's okay with @hairmare. |
Closed in favour of #1696 |
For now these are the raw results of
vue create ui
in the root while choosing the new Vue 3 default.Tasks
ui/
[Vuetify] Unable to locate target [data-app]
warning in testsFixes #1121