@Allan-EN-GB Thanks a lot.
I can confirm that using importStrategy: ‘all’ solves the problem immediately.
Looking forward to the update and again thank you very much.
Posts made by mpr
-
RE: Sourcemaps not generated after Quasar update anymore
-
RE: Sourcemaps not generated after Quasar update anymore
Thanks a lot. It’s good to know that there is already an issue for it. (Sorry I have not found it myself).
Good luck for finding the issue.
-
RE: Sourcemaps not generated after Quasar update anymore
I have the same problem. Until recently debugging of the Quasar App in Chrome worked fine, but now something is going wrong with the source maps.
As far as I can tell, it seems that the update to @quasar/app >= 1.9.0 brought the problem. It’s also not working with @quasar/app 2.0.1 for me.
I tried with different strategies for devtool, without the explicit setting and with ‘source-map’.
(By the way sometimes I see the use of ‘#source-map’. Is the # needed here or not ?)Debugging works fine in my environment for a very simple Vue app without Quasar, using webpack 4.43.0 and debugging with IntelliJ and Chrome.
Has anyone an idea what is going wrong and/or how to fix it ?
Thanks
Martin -
RE: [v1] QSlideItem How to identify item in the events left/right/action ?
@lucasfernog perfect, thanks a lot
Martin -
[v1] QSlideItem How to identify item in the events left/right/action ?
When you have a list of QSlideItems how do you know in the events which item was dragged ?
Maybe I am overlooking a solution but like Serge in Discord, I think that it’s necessary to pass additional data to the QSlideItem events which seems not to be possible.
e.g.
<q-list>
<q-slide-item v-for="(item,index) in items" :key=“index” @left=“onLeft(index)”>
…There is a codepen https://codepen.io/anon/pen/GzaMXv?editors=1011 from serge with a full example.
Thanks
Martin -
RE: Q-Select 1.0.beta
@Kentoncloud I assume that 128 in your picture is the id of the province. Then you will probably need the new prop ‘map-options’.
-
RE: [v1.0.0-beta.2] QUploader changed key name (was this.name, now file.name) ?
Hi @nothingismagick, thanks for your reply and the links. I already used the notes, but have not known the comparison of Matyas before.
Anyway as far as I can see the change of the key name of the file in the uploaded form data is not mentioned there.I‘am personally missing the fixed field name because of the reason mentioned in my post above and I don’t understand the advantage of this change.
I assume that the change was made because of the new batch option, but as far as I could test this is also working with a fixed file name. (For testing I derived my own Uploader from QUploader which used “file” as key name.)
I have opend issue 3318.
-
[v1.0.0-beta.2] QUploader changed key name (was this.name, now file.name) ?
While upgrading my webapp from 0.17 to 1.0.0-beta I noticed that QUploader does no longer use this.name (default ‘file’) as key name but the name of the uploaded file itself.
This makes it more complex to work with the file on the server side because the key name is unknown and e.g. the Spring parameter resolver “@RequestParam(“file”) MultipartFile file” can no longer be simply used.
I assume that there is a reason behind the change, but would it be possible to implement the previous behaviour in addition ?
(e.g. use attribute name and if defined set the key from it)Btw thanks for the excellent framework and for fixing QUploader headers and adding QUploader fields in beta.2
Martin