@quasar/qcalendar v1.0.0-alpha.4 Release!
-
https://github.com/quasarframework/app-extension-qcalendar/releases/tag/v1.0.0-alpha.4
update dependenices- fix(css): shift q-calendar-weekly__day-label so it’s not on border
- fix: validation for ‘now’ prop
- fix(css): .q-calendar-weekly__day-month position
- fix(css): .q-calendar-weekly__day-month–day-of-year position
- fix(css): q-calendar-daily__head-day.q-outside color
- fix(css): q-calendar-daily__head-day.q-current-day.q-calendar-daily__head-day-label color, border, and font-weight
- fix(css): q-calendar-daily__head-day.q-future-day.q-calendar-daily__head-day-label color
-
@Hawkeye64 You’ve been very busy … must be energised by the recent vacation …
Looking like an extremely strong App Extension … will it actually become listed as an official “component” at some stage?
-
-
@Hawkeye64 … I meant will it get placed in the “Components” list in the Docs.
Could it become an actual component rather than an “App Extension”? Is that technically possible?
I know technically that it’s an “App Extension” … but, once it is complete, will it continue to remain under the “App Extensions” in the menu of the Docs or will it get placed under “Components”?
This is a “marketing” consideration rather than a “technical” one.
Anyone evaluating Quasar … deciding to give it a try … is probably going to scan the “Components” list as a major factor in their decision whether or not to invest time in trying out Quasar … they are less likely to review the list of “App Extensions”.
To even find out about the App Extensions … they need to go to the App Extensions menu, click Discover App Extensions, and … only then … review the list of App Extensions …
A big difference compared to just scrolling down the list of “Components”
I know there might be arguments that it’s technically not a component … that it needs installing separate from the main Quasar system … and therefore it should not be listed under components …
BUT … it could have a big notice at the head of it’s document page stating that it is not installed by default and would need installing prior to usage.
-
@digiproduct I assume this argument has been made before. App Extensions are the answer to people, who wants to build their own components or extend existing ones or integrate totally other functionalities from another frameworks/libraries, without need to pollute the standard library. AE is ingenious idea, and common with other succesful systems, be it Python with PyPI or Javascript with NPM etc. There are different release cycles in standard library and user created libraries. There are different quality guarantees with those. AE components are not obliged to keep Quasar API conventions or any other “expected” behaviour. AE allows to build a community around Quasar which is crucial (developer traction). Keeping everything in “standard library” would be in effect closing the Quasar to developers (who would decide what is and what is not “worthy” of SL?), and that is why it needs to exist.
BUT you have a point, that AE system, AE components/libraries, AE ideology should be more promoted/presented/shouted. BUT, this AE technology/API/best practices, are as for now created and hardened, so I think it is quite wise to battle test this AE subsystem with several components and then and only then build a “presentation layer” with extension search, discovery etc. I am very grateful, that there already is such an easy way to incorporate those AE into your own projects. I assume that it will be slightly changed/upgraded in the future (as everything) but a realization, that somebody thought about that makes me sure, that everything with AE will be OK.
As for now, it is important to just write as many AE as possible and test more and more possible AE use cases. I’m somewhat sure, that the impact of this AE technology will greatly surprise us all in the future.
-
@qyloxe From a technical point of view, I agree with you entirely …
BUT … from a marketing point of view … getting the calendar and other notable App Extensions showing to prospective users is highly desirable …
AND … the first place they’re going to look is the list of components …
-
@qyloxe I know myself … as a new user having just entered the Quasar ecosystem a couple of weeks ago … the components list was the main deciding factor in drawing me into investigating Quasar further …
-
@digiproduct No, I don’t think it’d happen. We don’t want to bloat the core with heavy components.
-
@Hawkeye64 honestly, I would’t cry at all, if the rest of the compound, interactive components (Table, Tree, Carousel maybe, etc) would be pulled out of standard library / core, and converted to AE. It is orders of magnitude easier for a developer to contribute to single AE component than to create PR to the whole Quasar framework. Developer traction is my main concern in the plan of global Quasar domination
