@rstoenescu Perfect, nice to know there is a plan for it, and that I did not miss anything in the docs
The problem is that for navigation I guess you need to modes, one for menu mode and one for toolbar layout.
@s.molinari That makes sense, and in fact we are using the
vue-router, to be able to control the menu in both directions, but when it comes to sub menus (dropdownish), I am a little lost as to how to do that.
I can see that you too end up with some questions, so maybe we just need to be on the same page as Razvan
We have been working a little with quasar and the layout, and as I understand it the “navigation” part of the q-layout is really the main menu of the project, and q-layout know how to make change related to platform and screen width, besides maintaining state of the elements related to current route.
Now, we like to make menus that is a bit more complex (and dynamic, but the is just work). I bootstrap and other we have things like dropdown or menu components. What is the idea in Quasar ? need we nest q-tab or what is the philosophy for complex menu structure ?
@rstoenescu With a little luck we may get both
But the last one makes a lot of sense, I love it when things are modular, but we may change the name of the Quasar components, and then any future type definitions will then not work.
@rstoenescu The combination of
Vue.use( Quasar ) and WebPack2 seems like working against each other, I mean …
If all components are registered into Vue core as global components, then WebPack2 can shake all the tree’s it likes to, these components will not be seen as dead leaves, as noone can check if they have been used inside some templates ?
Or am I on the wrong track here ?
@dgk It alway wise to be careful when starting on an new adventure
The Quasar.start, as far as I understand it, is a way to make sure that some of the mobile platforms are properly initialized (when needed), no magic just a way to give Quasar a change to init som stuff early. If you just make sure this is in you startup function, there is really not much to it.
Quasar is just components, BUT the layout filosofi here is to use the same layout on different platforms, and therefor quasar is able to help you most if it controls things like startup and layout (q-layout).
Regarding webpack … it is true that the cli version makes a rather large Webpack2 setup, but this is NOT at all necessary, I have a single file version using webpack 1.x (and i also use typescript) and this works just fine. What you need as a minimum, is stylus, babel and a few defines (PROD, DEV and __THEME).
The quasar build utility is just a wrapper, nothing magic just trying to be nice
So I understand you concern I have just been over all this myself
@rstoenescu Perfect thanks, it all makes sense I just want to know what the basic filosofi was on these.
Just a quick one, is it possible to force navigation menu state off even on a big screen, and is it possible to make a “layout-view” fullscreen (so all headers and footers disappear) ?
@rstoenescu Ok, thanks … I will dig in a bit more on my own
@s.molinari I am not sure that it is the case, it could be related to the concept of what is considered “light” and “natural”, in a component model that has its roots in a more and less pure html API model.
That it is also hard to model in a syntax strong environment, makes it even more worrying, in my perspective.
When we start to use Quesar along with tsx files (I am working on this), I thinks this will be even more clear, as these component properties can be type defined in typescript, but VueJS components ($refs) still need some kind of unsafe casting.
Looks like your connection to Quasar Framework was lost, please wait while we try to reconnect.