javalinvue-example
javalinvue-example copied to clipboard
tipsy
Feedback (pros, cons, comments)
Cons ... No transpiling (can’t use the latest JS features without code breaking in old browsers)
I wonder if you could use the maven-frontend-plugin (or something similar) to do this.
I'm not sure. Since the JavaScript isn't exported as modules, I imagine it will have some trouble 🤔
This looks terrific! I'm a part of a small team of full-stack devs. We love Vue.js on the front end and a JVM stack on the back-end. We've been feeling pain for a while in having this split across two systems. We've been looking into Java template engines (last experience was with jsps and Thymeleaf) but this could well be a winner!
In the article you still use a JSON API to fetch data for the render. Can I ask why? It seems like rendering with javalin shared data would work fine. Have you tried this for data other than auth and run into trouble?
It's would work fine, but most of the apps I have are dynamic and will update data when you add/edit/delete. It's simpler to just have 1 way of loading data.
By the way, since I wrote this article I have started using the approach on two large projects at work without issue. It's making us very productive :)
Im testing this approach now too for our next applications based on micro services. Im in my early testing phase, but its looking good for now. I will keep you updated. Thank you very much @tipsy
I just. experimented with the vue-router, doesn't require much work... but if you want to get the state... thats another issue ;-) I guess i will push the router approach a little further back
For me the best part about the server side routing is that it renders the correct component on load, and that access management works the same as for the API.
Yes, thats what i noticed too that i would have to duplicate the access restriction. What do you think about only including views into the componentRegistration that the user has access to, according to the access manager?
I don't think that's required, the HTML itself shouldn't be sensitive. It would reduce the payload though, which is good :thinking:
I have a fairly big angular project (100 components) that im planning on doing a rewrite, i really like what i saw on the tutorial. in your opinion is it suitable to use the approach for a big project?
currently all the way down to IE8 but im trying to see whether it will be just chrome, firefox and edge
Yeah, this would be a bad idea for IE8, but it works really well for modern browsers. 100 components sounds fine, I guess it depends a bit on how big they are. My current project has 49 components, which results in a payload of 29kb (in other words, not an issue).
Thank you for writing this @tipsy, it has been a most enlightening read. Not only did you save me quite a bit of time, but convinced me Javalin deserves more than the cursory look I had given it.
After all these years it still impresses me how small libraries with just the right choices can often provide more value than huge behemoths. Thank you!
I'm glad you like it! I guess Javalin is the result of doing "just enough" for a lot of years. It's gained some weight lately with the extra modules, but they very much optional :)
Hello, is there a reason all .vue templates are always sent to the client (even login protected ones)? Isn't that kind of counter-productive?
@gringofe If the templates were split based on roles it wouldn't be possible to cache the bundle anymore (you would have to rebuild everything for every request). Sensitive data shouldn't be put into static HTML/JavaScript files, you would have the same issue if you put sensitive data in your app.js in a "normal" JavaScript app.
It might be counter-intuitive though, we could include it as a config option?
I don't think creating a config is necessary, I was just wondering if it's normal for all the files to be sent, since I am not doing a lot of frontend webdevelopment. btw, thank you for creating Javalin, it has been a pleasure working with it so far.
I was just wondering if it's normal for all the files to be sent, since I am not doing a lot of frontend webdevelopment. btw, thank you for creating Javalin, it has been a pleasure working with it so far.
Happy to hear it!
... for unit testing a web pack config could be created and you just run it as a separate process.
I'd be very interested to hear more about this if you manage to set it up.
Hi, Thank you for this. I love the approach.
It's probably my lack of understanding how webjars work, but I have been unable to get it to work with any Vue or Vuetify components. For a simple example, in layout.html, I substitute
<v-main id="main-vue" v-cloak> @routeComponent <v-main>
for
<main id="main-vue" v-cloak> @routeComponent <main>
and get a javascript exception:
Cannot read property "bar" of undefined Found in ----> <VMain> <Root>
If I leave layout.html alone, I get similar errors trying to use any other Vue or Vuetify component in the template hierarchy. It would be great if the example went a little deeper and showed the use of Vue components rather than just HTML markup like
Hi @lwhite1, glad you like it!
There really isn't more to it than what is shown in the docs/example. Once you add a WebJar to your project you need to rebuild (using Maven/Gradle/your-tool-of-choice), then you need to include the static files from these WebJars in your <head> (you can include them other places too, but using <head> makes everything easier.
You can look at https://github.com/tipsy/kotlin-admin-template for a more complete example.
Yes, you're right. It works ok, except that Vuetify doesn't see the icons and fonts it needs. Since it's material design, it's looking for Google's Roboto font and Google icons. The vuetify webjar doesn't seem to recognize them when they're brought in as standard links, or as webjars. I will see if I can follow the kotlin template code, (i'm using java) since that looks a little different. In any case, it's not a Javelin issue.
You probably just have to find the correct version if the mdi font. I can find it for you tomorrow!
Got it using your template example. All set. Thanks much
On Sat, Jan 9, 2021 at 11:05 PM David [email protected] wrote:
You probably just have to find the correct version if the mdi font. I can find it for you tomorrow!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tipsy/javalinvue-example/issues/1#issuecomment-757411111, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2FPASMYALRLFHB3ZDMHN3SZERQBANCNFSM4IIJPAHA .
Since im going to be adding some stuff about Vue3, i'd also like to put it forward that there is some kind of reloading for vue files now, just not for routes, so maybe put that as a pro now since its been fixed?
Basically, if you use the rootDirectory in EXTERNAL mode, and Javalin is running in Dev mode(ie, requests from localhost or through a custom env variable), it always re-scans the files each request, kind of like it does in unit tests. I Use this often when developing apps(and since I usually dockerize, its no sweat off my back). I even do the same for static files(non-webjar), since i dont use inline files often and rely on those for style. Actually, when working purely on the front end, the only time i need to rebuild and run the server is when I add a web jar, and otherwise, i just refresh the page. I can add this to the docs, might make sense to throw this in the bottom around the "tips and tricks" section.
The plugin has always supported that (I would die without it 😅), but hot-reload refers to updating the app without refreshing the page (so you won't have to recreate your state).
I will create a much richer docs page for the JavalinVue plugin soon, I will include that tip there :)