I'm fairly new to Vue and only learn a little bit of it. Actually it's my first time seeing this beautiful library (whatever you may call it ) And i saw many developers actually pulling many dependencies from npm like vueify, and many more. Now, I just want to ask. I'm only a beginner. and what i know is to just pull of my files and store them in my resources/assets/js folder and just do elixir on them. And, is it really a good practice to just pull of those dependencies and browserify/webpack on them regardless the size of the app i'm developing ? Humbly asking for opinions
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
That may sound like an odd question so let me explain why I ask it. I am just learning Laravel, Vue and Vuetify but I haven't found a coherent set of instructions that actually works for installing them except for this video. Based on the verification steps at the end, it appears that this procedure correctly installs Vue and Vuetify in Laravel.
Unfortunately, I can't find any course on learning Vuetify in Laravel, although this playlist seems pretty clear for a non-Laravel environment. Unfortunately, the playlist's installation instructions seem to result in a very different structure for the project which bears almost no resemblance to what I see in Laravel. And that is confusing me when it comes to actually writing code.
For instance, at the start of the third video, the narrator starts to go through the first Vuetify code that he is going to teach and the files shown in his IDE are very different than what I have in Laravel. While I do have a node_modules and public folder, as he does, I've also got a bunch of other folders, like app, bootstrap, config, database, resources, storage, route, and vendor but I do not have a src folder (nor most of its subfolders, aside from views). I am also lacking an App.vue file, the one he is editing at the start of that video.
I have no idea how to proceed after many hours of searching for videos and tutorials. I am afraid that I am missing a bunch of critical files that I will need but I can't think of any way to determine what those files are nor do I know where to find them.
I am keen to proceed with learning Vuetify but I won't make any progress until I can be certain that I have all the files and folders I need to proceed.
Vue is the most unopinionated framework you have come across. It doesn't require any folder structure (node_modules is imposed by node.js, not by Vue).
So, whatever you think works best for your current project is what you should go for.
Obviously, having this type of freedom can be confusing and counter-productive, especially for those who don't know what they want or don't have much experience. Those often need to be told by more experienced others: "try this thing, it's been tested, works pretty well".
If you're looking for that type of opinionated advice/structure, give Nuxt a try. Nuxt was developed by people using Vue on a daily basis who, at some point, realized having a similar structure across projects might be beneficial and would allow for even faster prototyping.
If all you need is to be certain you're not missing anything crucial, you're not.
All you need to run Vue (and everything that's associated with it, including Vuetify) is one element's id in your page and the vue script loaded, at which point running
new Vue({ el: '#host'})
will create a Vue instance and use the element with id="host" as template.
Since Laravel 5.4, the default method to compile assets is using Laravel Mix, instead of elixir.
I know that "Mix" uses WebPack by default to compile the assets.
What benefits does this method bring?
The Mix also allows you to compile without WebPack, and this always
produces files that are smaller in size and work the same.
This is entirely incorrect. Have you attempted to configure any of the myriad options to optimize your bundle at all?
Start with the webpack-bundle-analyzer plugin. This will give you an idea where your bloat is, what is duplicated, and where to start trimming your application.
Between uglifying, chunking, deduplification, minification, etc. you'll have in the end compiled resources that are far from "large".
Now I'll grant you it has a steep learning curve comparative to other tools, regardless, WebPack is an incredibly powerful tool, you need to take the time to learn it's configuration capabilities.
Care to elaborate on what you mean by working the same? I run several production applications as well as a number of smaller personal projects. I never seem to get different results after each build.
But in the end it's just a tool. A tool like any other tool, you use what you feel comfortable with and what fits for the job. There's a reason it as selected as the default, though. And it isn't because the maintainers are ignorant by any means.
I didn't find any good boilerplate, as I want. I need boilerplate with:
React
Redux
Express
Routering
Server-side rendering
Thunk middleware
Hot reload
Css-modules
Webpack
Babel
Eslint
Dev and Prod mods
I didn't find anything in all github! Making it yourself is very very complicated - many errors, stupid things! I spent 2 monthes for this and didn't achieve the desired result.
I strongly recommend working through this: https://github.com/verekia/js-stack-from-scratch
Aside from the fact that it covers everything you asked for an more, this repository actually walks you through the setup of your own 'boilerplate' which is a far more valuable tool in the long run.
I have a simple boilerplate repo that I built up based on that repo here: https://github.com/savish/sample-js-app
I have used backbone boilerplate on the past
https://github.com/backbone-boilerplate/backbone-boilerplate
I want to use marionette on my next project and I have found this
https://github.com/BoilerplateMVC/Marionette-Require-Boilerplate
My question is if it's a good idea to go with the marionette boilerplate or start form scratch.
As an aside, I'd like to suggest you give Yeoman a shot for scaffolding your first Marionette app. Yeoman works via what are called "generators", and provide much more than the the above Boilerplate MVC can offer you (Chai and Sinon for testing, Bower for client-side package management, etc...). Plus, Addy Osmani, who runs backbone-boilerplates is one of the heads of the project. Check out generator-marionette here.
I haven't used BoilerPlate, but glancing through it, it certainly seems like a valid approach to writing Marionette apps. If you're just getting started it will certainly help you see how the various pieces are supposed to be used. One gripe I've got is the folder structure. I prefer to break my applications down into modules, and then add models, collections, views, etc under each module. But this will certainly get you up and running quick, and there's nothing stopping you from customizing it to suit your needs.
I agree with others here: it is a useless limitation to imitate a folder structure that follows the 'old mvc model for server-side code'. You will remain more flexible further down the road if you think of your application strictly as completely self-containing modules, i.e. they contain their own controller/router/views/collections/templates etc. You can have a separate folder structure for shared code that is not a module, although anything can be made a module :)
Regarding boilerplate code and generators: i think in the beginning you should actually NOT do it, because you won't understand what you're doing. But that's just my personal opinion.
I'm building several sites that need similar "modules." For example, the sites may have the exact same login system, forum, etc.
Is there a way I could build these modules once and just "drop" them in these various sites? Some of the challenges I see:
Keeping the code consistent in the various sites. Any changes made to a module should propagate to all of the sites using that module. I guess I need a way to upgrade?
Database: these functionality need to work as part of a bigger application. Maybe the module needs to define relationships with other tables in its respective site.
I'm sure there are more problems. I think I should be looking at this: https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home, but I don't have any experience with it.
So, I'm looking for solutions, suggestions, or more problems to this idea.
You can create and use third party packages by adding them to the third party folder (which is new for CI 2). There is not much about it in the docs, but i found this.
http://codeigniter.com/user_guide/libraries/loader.html
You can autoload the third party packages in the autoload file. Packages can have their own controllers, models, views etc.
Interestingly, Phil Sturgeon wrote a bit (http://philsturgeon.co.uk/blog/2010/04/codeigniter-packages-modules) about packages not being modules (in the strict sense of the term), but you could probably use third party packages for what you need.
I would write them as libraries and use Git submodules to manage each module. Phil Sturgeon actually just wrote a great post about doing this in CodeIgniter.
If you're not using version control, I can't see an easy way to sync across all of your applications. Yes, HMVC will let you break apart your application into actual modules, but it won't help in syncing those modules across your applications.
Here is my question about 'Database communication in modular software'
that you may find useful.
I'm little bit familiar with Drupal, and as a modular application, I think it can be taken as good example of how relationships between modules should be defined.
Here is one good post about art-of-separation-of-concerns
I would like to hear if you have run into some concrete challenges, solutions and references concerning modular design in CI.