RFC (Request for Comments) Template

Please select your type of RFC (one or more):

Put an x in the boxes that apply

• Change ?
• Method ?
• Behavior ?
• Research ?
• Innovation ?

Other

• Start Date: (fill me in with today's date, YYYY-MM-DD)
• Target Major Version: (2.x / 3.x)
• Reference Issues: (fill in existing related issues, if any)

Does this introduce a breaking change?

Put an x in the box that applies

• Yes
• No

Proposed RFC

s your feature request related to a problem? Please describe.

Some of the most useful and complex Quasar components are difficult to implement with a drag and drop library. See qTable and qTree.

For example If I wanted to implement drag and drop within qTree with this library
https://github.com/SortableJS/Vue.Draggable/blob/master/example/components/nested-example.vue
I would need to wrap q-tree__node within . I have no easy way of doing that.

Describe the solution you'd like

Official support and guidance for a Drag and Drop library which supports mobiles and tablets.
It would mean that components structured in such a way that a well known drag and drop library
such as the above could easily be implemented.

Examples in the different components docs how the supported library could be used.

I don't need support for multiple libraries but only one.

Describe alternatives you've considered
Several drag and drop libraries.I have also rebuilt (bodged) both qTable as well as qTree (just finishing) because of this. Recreating those components is a lot of soul destroying work just to get drag and drop working.

As you can guess I am not the only one to do this see forum posts:
https://forum.quasar-framework.org/topic/3543/drag-and-drop
https://forum.quasar-framework.org/topic/4010/drag-and-drop-in-qtable-did-anyone-succeed
https://forum.quasar-framework.org/topic/4595/q-table-rows-drag-and-drop
https://forum.quasar-framework.org/topic/2619/drag-and-drop-data-table-column-ordering
https://forum.quasar-framework.org/topic/3069/q-list-sortable/2
and more ... I won't list all here. But it is not difficult to see that a lot of people will want drag and drop and will be implementing (most likely badly) their own solutions.

This is one of the most missed features in Quasar IMO. So hopefully you consider it.
Thank you for the great work.

RFC (Request for Comments) Template

Please select your type of RFC (one or more):

Put an x in the boxes that apply

• Change ?
• Method ?
• Behavior ?
• Research ?
• Innovation ?

Other

• Start Date: 2020-02-13
• Target Major Version: 2.x
• Reference Issues:
  quasarframework/quasar#6135
  quasarframework/quasar#5924
  quasarframework/quasar#5702
  quasarframework/quasar#5412
  quasarframework/quasar#4714
  quasarframework/quasar#1670

Does this introduce a breaking change?

Put an x in the box that applies

• Yes
• No

Proposed RFC

One of the most talked about and asked for features.

Examples
https://swiperjs.com/
https://kenwheeler.github.io/slick/
https://flickity.metafizzy.co/

RFC (Request for Comments) Template

Please select your type of RFC (one or more):

Put an x in the boxes that apply

• Change ?
• Method ?
• Behavior ?
• Research ?
• Innovation ?

Other

• Start Date: 2021/03/08
• Target Major Version: 2.x
• Reference Issues: none

Does this introduce a breaking change?

Put an x in the box that applies

• Yes
• No

Proposed RFC

A migration path for existing AE and conventions about it shall be defined.

The current proposed way is to use Git/NPM tags.

Qv2 starter kit is currently usable via quasar create my-project --branch next so we must adapt to this convention
When Qv2 becomes stable, starter kit next branch will become dev/master and current master will be moved to quasar-1 branch.
Commands to create a project will then become

quasar create my-project --branch quasar-v1 // Quasar 1 project creation
quasar create my-project // Quasar 2 project creation

Qv2 compatible AEs which won't support Qv1 too must release a new major version under next tag.
AEs which can work the same with Qv1 and Qv2 without breaking changes shall release a new minor version and tag it with both latest (the default) and next, to preserve usage consistency. The Qv2 branch for these AEs must be called next (it's just for consistency, it doensn't actually change anything).

In this way, devs will be able to install the Qv2/Vue3 compatible version using quasar ext add <my-ae-id>@next, while current Qv1/Vue2 version will still be installed by the default command (quasar ext add <my-ae-id>).
All Qv1 AEs which cannot work with Qv2 too will enter support mode as soon as the relative Qv2 version is released, since we won't be able to publish any more breaking changes released which following semver (the next major version will be taken by Qv2 version).

When Qv2 becomes stable, next branch will become dev/master and current master will be moved to quasar-v1 branch and the last release published under quasar-v1 tag.
From that point onward, people would be able to install AEs like

quasar ext add <my-ae-id>@quasar-v1 // Add Quasar 1 compatible AE
quasar ext add <my-ae-id> // Add Quasar 2 compatible AE

After Qv2 becomes stable, we shall add an automatic check into @quasar/cli which, if Quasar 1 is detected in the project, automatically adds the @quasar-v1 tag reference

All Qv2 compatible AE which is not compatible with Qv1 should implement a check into install.js which force the installation to fail if Quasar version isn't supported, displaying into console the correct command to run.

Eg.

This AE version isn't compatible with Quasar 1, please run `quasar ext add <my-ae-id>@quasar-v1` instead or upgrade "@quasar/cli" to latest version to leverage correct AE version auto-detection

1. Claim

   • Current changes to root html font-size does not scale all components consistently.
     • Hard coded px values make it impossible to correctly scale Quasar without end users either:
     • forking it and changing those hard coded values or
     • overriding all Quasar CSS classes.

2. Background

   • There is a need to scale Quasar UI to accomodate end user requirements for UI density (e.g. highly technical applications requiring increased UI density and accessibility concerns with decreased UI density).
   • Overridding all of the exposed Quasar stylus variables to use rem (rather than px) in an attempt to scale the Quasar UI using the HTML font-size is ineffective.
   • There are a large quantity of components that have hard coded px font-sizes, padding, margin, etc. (e.g. the table component does not scale it's td font size--it's always 13px) so these components do not respond correctly to root font-size changes.
   • There are also components that were coded with rem values so the scale is inconsistent when changing the root html font-size.

3. Research
   Here is a list of components where anx is placed if the stylus file for the component uses a specific type of css units:

4. Proposal
   a. Apply rem sizing units to component stylus files currently using hard coded px values.
   b. Convert all hard coded px values to Quasar stylus variables that are exposed to the user with default values set to current px values. This would allow users to override to rem units as they see fit.

5. Impacts
   Moving this into core is likely to have a negative impact on developers currently working with any type of CSS overrides, as scaling will be an issue that they haven't considered. Also, other app-extensions MIGHT have similar problems / so moving this into core at the current time is inadvisable.

Broad browser acceptance makes this a viable approach - except for IE11 because according to caniuse:

IE 9, 10 and 11 do not support rem
units when used in the "line-height"
property when used on :before and
:after pseudo elements
(https://connect.microsoft.com/IE/feedback/details/776744).

6. Approach
   Providing stylus files is well within the realm of possibilities of an app-extension, although it will likely be necessary to create a new type of AE-API interface for totally overriding stylus imports in order to reduce artifact size. (Note: Maybe I am wrong about this - will need feedback. Denjell)

7. POC
   In order to test the viability, the following approach is recommended:

   • Create an app extension
   • Choose a relatively simple component (like QAvatar or QBadge) to convert
   • Create the new stylus rule overrides
   • Build all potential artifacts
     • web, all browsers
     • electron, all OS's
     • cordova iOS and Android

8. Future
   Once we've validated the approach, all style resources should be converted appropriately in the context of an app-extension.

If, however, we are able to discover a non-breaking method where this could be integrated into core, such an approach would be more favourable.

9. Participants
   The Ruths.ai development team is willing to help contribute to whatever solution is deemed best for the framework.

Prepared by Denjell, Josh Davidson with the statistical analysis help of LucasFernog
Ref: quasarframework/quasar#4246

RFC (Request for Comments) Template

Please select your type of RFC (one or more):

Put an x in the boxes that apply

• Change ?
• Method ?
• Behavior ?
• Research ?
• Innovation ?

Other

• Start Date: 2020-12-14
• Target Major Version: 2.x

Does this introduce a breaking change?

Put an x in the box that applies

• Yes
• No

Proposed RFC

Add the possibility to use templates while creating layouts/pages/components/boot with quasar cli.
Currently, creating any file using the quasar cli results in some default code being generated for the file.
Some component such as QDialog almost all implement the same code. Adding the ability to specify the template
of the component at create time using a command such as quasar new component --template dialog which would result in the component being created with the code recommended here would reduce some repetitive task.
A new folder named templates could be added in the src folder allowing users to store custom templates they could use to create pages or components.

Possible Folder Structure

└── src/
│   └── templates/
│       ├── components/
│       │   └── dialog.vue
│       ├── layouts/
│       │   └── youtube.vue
│       │   └── github.vue
│       ├── page/
│       │   └── login.vue
│       │   └── profile.vue
└── quasar.conf.js

RFC (Request for Comments) Template

Type of RFC

• Method

Other

• Start Date: 2021-09-08 (YYYY-MM-DD)
• Target Major Version: N/A
• Reference Issues: (there are no issues, yet)

Does this introduce a breaking change?

• N/A

Proposed RFC

Request Management Flow (bugs, feature requests, etc.)

Issue Template Changes

See the test repo: https://github.com/yusufkandemir/github-issue-form-test

Issue Forms

GitHub has a new feature called Issue Forms, which allow creating forms with validation and stuff for creating an issue, which is very useful since a lot of users don't fill in the template as we want to be. I converted our issue template to a form and made some extra changes to improve the quality and prepare for some future plans to work with bots, like automatically labeling or assigning people, looking at the selected options, etc.

You can check the test repo to see how created issues look like, and try to create new issues to experience how it feels like to create new issues with the form

Issue Template Chooser

GitHub has a thing called Issue Template Chooser, it allows choosing different templates between bug reports, feature requests, etc. when creating an issue. We are currently using it on our repo for issue and feature requests for Qv1 and Qv2 respectively. It is configurable, so I have gone ahead and disabled the creation of blank issues, and added extra entries explaining and redirecting to our other channels like GitHub Discussions and Quasar Discord Server.

Please ignore the plain Bug report entry, it's for testing purposes

Updates to Feature Request Flow

We will get rid of the Feature Request type when creating new issues, and we will redirect users to use the Ideas/Proposals section in Discussions instead. After a post gets enough interaction, has enough information to get implemented, and gets approved by our staff, we will convert the discussion to an issue. Then we or someone else can create a PR referencing that issue.

Bots and Automation

I made some thinking and research, inspected a lot of bots, and selected these bots among them to be useful for Quasar:

• Stale: Close stale Issues and Pull Requests
  • We will set daysUntilClose to false to disable auto-close, as per @pdanpdan's recommendation.
• No Response: Close issues where the author hasn't responded to a request for more information
• Welcome: Welcomes new users
  • Could be useful for increasing interactivity and encouraging new contributors
• Release Drafter: Drafts your next release notes as pull requests are merged into master.
• Prosebot: Probot App to help you write better on GitHub.
  • Spelling, prose, etc. checking. It will be especially useful for reviewing documentation changes
• Boring Cyborg: Add labels on PRs based on the FilePaths & Welcome First time users & much more
  • Issue labeling based on the path (apply area/app label when changes are made to app/ folder for example
  • Welcoming and encouraging new contributors (we can use this instead of the welcome bot)
  • Verifies commits and PR titles to match regex (optional)
  • Checks if PR is up to date with the branch
• Ranger: A sidekick for repo maintainers. It reduces the burden of repository maintenance by automating common tasks.
  • Reply with specific answers depending on the labels(configurable), an example scenario:
    • A user opens an issue asking for IE11 support, a human tags the issue with no-ie11, then the bot automatically comments as "IE11 support is not considered, please go see this issue for more information and closes the issue")
    • We can find better use-cases.
    • We can use it to reply to questions and help requests to redirect users to other suitable channels.
  • It can automatically close issues when marked as duplicate, wontfix, etc.
  • Can label the issue/PRs of GitHub sponsors, we can use this to prioritize issues of sponsors.
    • But it applies the same tags to all sponsors.
    • So, we can create our own bot for this feature to check for different labels for different tiers, if needed.
    • I think this approach may result in a good impact on potential sponsors that are seeking direct benefits.

RFC (Request for Comments) Template

Please select your type of RFC (one or more):

Put an x in the boxes that apply

• Change ?
• Method ?
• Behavior ?
• Research ?
• Innovation ?

Other

• Start Date: 2020-03-15
• Target Major Version: 2.x
• Reference Issues: (fill in existing related issues, if any)

Does this introduce a breaking change?

Put an x in the box that applies

• Yes
• No

Proposed RFC

The proposal is to have native currency formatting with QInput

RFC (Request for Comments) Template

Please select your type of RFC (one or more):

Put an x in the boxes that apply

• Change ?
• Method ?
• Behavior ?
• Research ?
• Innovation ?

Other

• Start Date: 2020-02-16
• Target Major Version: 2.x
• Reference Issues: (fill in existing related issues, if any)

Does this introduce a breaking change?

Put an x in the box that applies

• Yes
• No

Proposed RFC

QTable in Quasar Framework is pretty good. Very profession and easy to use.

However, there have been many options requested to make it better, some of which have already been implemented. This is not an exhaustive list:

1. Expanding row with child table
2. Expanding row with tree-like child rows (quasarframework/quasar#4099)
3. Loading data from server enhancements
4. Grouping rows (quasarframework/quasar#5981)
5. row-class prop with callback (quasarframework/quasar#5959)
6. Drag and drop support (quasarframework/quasar#5890)
7. Column resizing (quasarframework/quasar#5890)
8. expand/collapse row animation (quasarframework/quasar#4380)
9. Alternating rows color support (quasarframework/quasar#4037)
10. Optional column prop support (quasarframework/quasar#1058) done (v1.12.0)
11. Multi-column sorting

RFC (Request for Comments) Template

Please select your type of RFC (one or more):

Put an x in the boxes that apply

• Change ?
• Method ?
• Behavior ?
• Research ?
• Innovation ?

Other

• Start Date: 2020-02-19
• Target Major Version: 1 / 2
• Reference Issues: quasarframework/quasar#5378

Does this introduce a breaking change?

Put an x in the box that applies

• Yes
• No

Proposed RFC

Generate route definitions automatically, by reading the folder structure of the pages directory with the option to override on a route level using meta files.

Requirements

Configurable as to whether it'll generate routes or not (default Off).
quasar.conf.js

framework: {
  autoRoute: boolean | object
}

The following folder structure:

└── src/
│   └── pages/
│       ├── pages.vue
│       ├── dashboard/
│       │   └── dashboard.vue
│       ├── user.vue
│       ├── user/
│       │   ├── index.vue
│       │   ├── query.vue
│       │   └── __underConstruction.vue
│       ├── blog_category.vue 
│       ├── blog_category.meta.js 
│       ├── blog_category/
│       │   ├── index_[post-id].vue
│       │   └── index_[post-id].meta.js
│       ├── games!.vue
│       ├── games!.meta.js
│       ├── !.vue
│       └── !.meta.js
└── quasar.conf.js

Generates the following routes:

[
  {
    name: 'pages_index',
    path: '',
    component: () => import('pages/pages.vue')
  },
  {
    name: 'pages_dashboard_index',
    path: '/dashboard',
    component: () => import('pages/dashboard/dashboard.vue')
  },
  {
    name: 'user_index_parent',
    path: '/user',
    component: () => import('pages/user.vue'),
    children: [
      {
        name: 'user_index',
        path: '',
        component: () => import('pages/user/index.vue')
      },
      {
        name: 'user_query',
        path: 'query',
        component: () => import('pages/user/query.vue')
      },
      { /* NOTE: Route omitted from production build */
        name: 'user_underconstruction',
        path: 'underconstruction',
        component: () => import('pages/user/__undercontruction.vue')
      }
    ]
  },
  {
    name: 'blog_category_parent',
    path: '/blog/:category',
    component: () => import('pages/blog_category.vue'),
    children: [
      {
        name: 'blog_category_index',
        path: ':post-id?',
        component: () => import('pages/blog_category/index_[post-id].vue')
      }
    ]
  },
  {
    name: 'games_wildcard',
    path: '/games*',
    // Not lazy loaded as the meta file would say `lazyLoad: false`
    component: 'pages/games!.vue' 
  },
  {
    name: 'wildcard',
    path: '/*',
    component: () => import('pages/!.vue')
  }
]

Routing Conventions

1. If a .vue file and a path below it match names (including brackets and underscores), the .vue file must be a router-view and the folder beneath it are its child pages. If in the children, there is an index.vue file, it is considered "pathless" and would be the first page to be shown when navigating to that route. If there is a .vue file which matches the parent folder, that'll be the default route otherwise (when no index vue file exists) and will also be considered pathless.

2. _foo - an underscore in front of the word means the word is a parameter. So, in the example vue file baz_foo.vue, "foo" is a parameter for "baz". There can be multiple parameters such as baz_bar_foo.vue.

3. [foo] - brackets around the word means it is optional. A path or a parameter can be optional. /[foo] would be an optional path. In baz_[bar].vue, "bar" would be an optional parameter for "baz".

4. /foo! - an exclamation mark after a folder name means it is a wildcard path. So, a folder with the name /foo! will translate to /foo/*. In most cases, you'll also need to add a same named .meta.[js|ts] file below the wildcard path (folder) to add your specialized routing rules, including any reroutes to a 404 page, where necessary.

5. A same-named .meta.[js|ts] file will be a container for any additional overriding, validation, guarding, etc. More details on this is below.

Example Meta File / Override route info

index_[post-id].meta.js

export default {
  lazyLoad: true, // Should this route be lazy loaded?
  route: {
    beforeEnter: (to, from, next) => {
      console.log('Im in a route guard!')
      next()
    }
  }
}

With the above meta file defined, the route for pages/blog_category/index_[post-id].vue will now look like:

{
  name: 'blog_category_index',
  path: ':post-id?',
  component: () => import('pages/blog_category/index_[post-id].vue'),
  beforeEnter: (to, from, next) => {
    console.log('Im in a route guard!')
    next()
  }
}

Everything under route: { } will be assumed as standard vue-router properties and will in turn be added directly to the route.

Additional properties will go on the same level as route: {}.

Meta File MeProperties

• lazyLoad: boolean = true - Whether the route should be added as a lazy loading route or not.
• parameters: ['param1', 'param2', 'param3'] - These parameters will be added to the route, for instance a file some-path.vue with this meta file property set would have a path generated like some-path/:param1/:param2/:param3. The idea for this is to avoid long file names when a route needs many params.
• route: RouteConfig = {} - RouteConfig propertes which will be attached to the generated route i.e beforeEnter.

Layouts &

This is dealt with in point 1 of the Routing conventions above. It is up to the developer to chose what file they would like to use as a layout and also how that file is named. For instance, a layout file could be defined like so:

└── src/
│   └── pages/
│       ├── pagesLayout.vue
│       └── pagesLayout/
│           └── index.vue
└── quasar.conf.js

It would then be clear to the users this was a layout but because there is a folder matching the file name, it would know that there is a <router_view /> contained within that file and the files below the same-named folder are the router-view's child pages.

To index.vue or not to index.vue?

It would be up to the developer to decide if they would like to use index.vue as the route / pathless view of that route. Point 1 of the convention again gives us a way by allowing us to either use index.vue or a file with the same name as the parent folder. index.vue if specified will always take precedence over a same named file.

Dev only pages (__something.vue)

These will only be generated in the routes.[js|ts] file when running in dev mode e.g quasar dev.

Development Notes

We will refer to the UI Kit for code generation regarding fetching of files and routing (see: https://github.com/quasarframework/quasar-starter-kit-ui/blob/master/template/ui/dev/src/router/pages.js) however, we will need to make sure the call to require.context() uses the fourth param lazy so as to honor lazy loading components.