Sorry about that. I should have looked deeper.
How about this Razvan? https://github.com/bearjaws/node-wget
Seems to take proxies into account. I’ll make an issue in the CLI and work on this.
Great to hear you are recommending Quasar! It needs to be said though, the API is still evolving and won’t be “BC fixed” until version 1.0 is released. Please also take that into account.
I found an issue fairly similar to yours and this links to what seems to be a possible solution. https://github.com/jspm/github/issues/59#issuecomment-167107576
Since it seems to be a settings iisue, we’ll need to find the right ones for you. That is about all we can do.
Also, please link the PR here if you could. I am, and I am sure others finding this thread would be, interested your the solution.
Thankyou for the kind words.
Currently Quasar supports both Cordova and Electron. In the bit more distant future, Weex could possibly offer a better road to native applications for Quasar.
PWAs are another beast though and Quasar is PWA ready. Only the wrapper is missing.
Native apps with Vue 2.0 made possible now with Weex, Alibaba’s new development platform for iOS and Android, which is based on Vue. It is a great milestone for Vue. I would guess it will be only a matter of time to be able to use Quasar to build native apps? Maybe?
I need to expand on why I think this kind of opinionation is good.
Think about all the devs using Quasar all creating the code for routes, which are results of their decisions. Surely, there is a ton of duplication, which means wasted effort.
Now imagine, this coding of decision results is taken away from them all. Surely, your argument would be, “but now their hands are tied.” And you’d be right.
However, now they would come to a central place and add their missing and needed decision to the code of the router (or ask for it). Being the decision is programmed -> BAM!, then every other of the 1000s and 1000s of devs using Quasar (I’m looking into a prosperous future) also get that feature too, instead of them all possibly reinventing that wheel.
I also realize this is where software bloat comes from too. So, this convention over configuration game is always a double-edged sword. But, a routing system is simple or modular enough, that bloat shouldn’t really be a big concern.
Those are all great examples of decisions you’ve made. And currently the routes you are creating are results of those decisions - for each and every page your app needs. The routes or routing logic are not the decisions themselves.
What I am thinking about is to program the decisions themselves, which are then decided upon by following certain conventions. In other words, if you do something a certain way, the routing system automatically knows how to route, because of that. Could you imagine your scenarios in that kind of format? What you posted would be a great start to all the decisions such a routing system should encompass.
I realize that means opinionation (but we are talking about a framework, which is always opinionated, right?), but it also means simplicity, once the conventions are known to everyone. It would mean never having to touch routes at all, but rather just learning the conventions and following them.
It would also help solve the often posed question, “How should I structure my very large SPA?”. If we program in the decisions for the client developers into the routing system, they don’t need to make them, they just do what is needed, according to the conventions. Not sure that is at all a good thing, but for beginners and intermediates and lazy devs, it certainly is. LOL!
In other words, to me the routes system as it is, is just a big configuration file. You could easily create YAML for what the routes stand for and compile it all together at run time to the routes system, as it is. So, I am suggesting this configuration can be replaced by conventions, which I believe is the better way to program.
Convention over configuration, right?
Oh, and I’d leave this as an alternative routing plug-in. So, that would basically side-step the opinionation concerns. (But, I am of the opinion, that this kind of opinionation is always the good kind. )
Ok. But, routing is just a bunch of logical decision, right? Like, if “/” -> load the home page or if “/blog” -> load the “blog” page, etc. etc. You might also have some sort of parameters too, which also means some sort of handling, which are also always decisions. In fact, the parameter handling decisions are also “pre-decided”.
What I’m considering is a routing system, which is convention driven and not a set of decisions written in code. For instance, if you have the convention of following a certain file system pattern, then you only add the files. The routes are, thus, automatically created. You don’t have to touch the router.
I am just wondering if it is worth the effort and will be flexible enough.
Woah! Throwing me a curve ball, ey?
I’ve seen nuxt, but haven’t had anything to do with it directly.
Ok. You are right about the single component being possibly used for multiple pages, but in the end, there is always something used to key in the right content or child components to be used on each page, which uses that single component, right?
This is a noob question about Quasar with a not-so-noob thinking behind it. So, please bear with me.
What I’d like to know is, what kind of components can be “navigable”, meaning what component can represent a page within an app? My concern is currently manually having to add routes and I’m thinking along the lines of an automated routing system. So, if I get the answer to my question, I’ll see if I can continue my train of thought.
They are similar. However, Quasar has more features available to allow for RAD, like CLI commands to create components and layouts (also custom ones). Quasar is also developed more with performance in mind. Quasar offers more components. Quasar has both material and iOS styles to choose from. Vuetify only has material. Vuetify has a bit more concentration on SSR (currently).
Here are some past threads, which might answer your question.
Oops. I put the “icon” in the wrong place.
Should have been:
<q-fab class="absolute-bottom-right" @click="alert()" classNames="primary" active-icon="alarm" direction="up" style="right: 18px; bottom: 18px;" > <q-small-fab class="white" @click.native="$refs.drawerleft.open()" icon="some_other_icon"> some-button </q-small-fab> </q-fab>
Looks like your connection to Quasar Framework was lost, please wait while we try to reconnect.