You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 6, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 6, 2025. It is now read-only.
This "excellent" package is still in beta. I know that the product can still be improved but a lot of company refused to use beta product. So i think it would be nice to publish a real release, event if there is still some "small bugs"
From reading #674, it looks like Angular v8 may be the proper time frame for a possible GA of @angular/flex-layout. That could be sometime around April 2019 if I'm not mistaken.
With reference to #871 I also find it unusual for a minor version upgrade to require a major upgrade of a subsystem - in this case Typescript. It means we remain - for a while - on a version of Flex which has some bug fixes, but isn't "version 7", but isn't the latest version of "version 6". Can the team also adopt the policy that subsystems are not upgraded except when a major version implemented?
In other words, minor increments should only be for bug fixes.
With reference to #871 I also find it unusual for a minor version upgrade to require a major upgrade of a subsystem - in this case Typescript. It means we remain - for a while - on a version of Flex which has some bug fixes, but isn't "version 7", but isn't the latest version of "version 6". Can the team also adopt the policy that subsystems are not upgraded except when a major version implemented?
In other words, minor increments should only be for bug fixes.
It's to keep in line with Angular's major versioning. That way you know that Flex layout 7 works with Angular 7, 6 works with 6, etc. I think there's a lot more value by not having to guess at major versions than to stick with purely semantic versioning. I totally see your point though.
@RichardC64, Ivy hasn't landed yet so IMHO that answer remains valid and up to date. I'm not sure Ivy will be the default renderer before @angular 9.0.0+. Be prepared for some more beta period until... 2020?
This library has been in 'beta' far far longer than anything else I've ever seen. Doesn't it lose meaning at this point? Why not just make it official?
Although I've read #674 (comment) I 'm starting to believe that this project will never be released.
Also, how is possible to figure out which versions of the other @angular libs this project is compatible with?
This library is major-version aligned with the versions of Angular (v8->v8). We keep it current with all future releases once Angular CDK issues a compatible release (since we depend on them).
As for stable release, if you don’t believe we’ll ever make it there that’s fine. Plenty of people have chosen not to stick around and wait. You have to make the right choices for your project. However, stable release or not, we believe this library provides tremendous value. Not only that, just because you don’t believe we’ll make it doesn’t mean we never will 😄 .
Personally, I’m waiting until the v9 release to restart efforts towards the redesign. Doing so earlier means likely getting crushed by the freight train that is Ivy.
Reacted by Benjamin Charity, Michael Prentice, Suraj Tambe, Vlad Dumbrava and Abhishek Datta
Now angular v9 is also released with default Ivy. When are you planning to do stable release? I saw the library v9 version updated 7 days ago still in beta.
Reacted by Julien, LinboLen, Krishna Teja Mannam, Carlos Morales and Abhishek Datta
Reacted by Lucas Shoji, François Dexemple, Mark Van Aken and Abhishek Datta
Angular 9 has been out for 3 months now... this library has to be record breaking in how long it has been 'beta' in name only. @CaerusKaru this 'redesign', are there any blueprints, scopes, roadmaps etc etc that can indicate to what degree breakage will occur? Can people expect this library to go stable this year or is it going to continue as is?
Somehow I doubt that in the history of software, this library sets the record for longest beta, but point taken. The redesign is in #1185, and comments of all types are welcome. It is an enormous departure from the current library, and even with Angular schematics, I doubt it's an easy feat to introduce. Add to that the fact that the framework team has not seen or discussed this new proposal yet.
I can't offer a tangible update at this time, except to say that I share your frustrations. I'm not going to stop pressuring the team to pick this up, but it's difficult given their shifting priorities.
@CaerusKaru Why don't you just remove the word "beta" from the release schedule. Beta in my mind is to proffer a piece of software to gain further customer feedback before going live. I know for certain that flex-layout is inside multi-million pound software applications, hardly beta. I don't think anyone would really know or indeed care what is around the corner, even if it is a complete redesign.
I understand your frustration, no one more than I would love to see as many people use (and benefit from using) Angular Layout. Unfortunately, the factors you've laid out are not enough to sway the project planning for the Angular team.
The Angular team is not interested at this time in garnering interest towards or driving up use of this library
The length of time in beta is immaterial to the Angular team, since they don't have an interest in fully supporting it anyway
While no solution is perfect, there are solutions that are deemed "acceptable" and not, by the standards endorsed by the Angular team
We're not talking about just minor breaking changes here. The breaking changes could change the entire structure and usage of the library itself. See rfc: new layout system #1185 for more detail.
The "excuse" here is that the Angular team is finite, and its resources finite. My, and our consumers', will is not enough to override this simple fact. I'm sure if 100% of respondents ranked Angular Layout as their number one priority in the annual Angular survey, that might change. Until then, this project remains in beta unless announced otherwise.
Reacted by Michael Prentice, Logan Dupont and Carlos Morales
I've done this for a few apps now and it basically boils down to
Directly apply the same CSS (Flexbox, Grid, Media Queries, etc) that Angular Flex Layout currently applies in your app
Use CDK Layout for observing breakpoint changes in TS
This may also end up being one of the safest ways to move towards the new "Angular Layout" redesign as you would then be free to start using those new APIs when they are stable w/o worrying about having two layout libraries in the app or having conflicting directives.
As a feedback, I switched to using Tailwind CSS and it's an absolute bliss. Flex Layout is nice on its own, but with Tailwind you gain the same simplicity, and added value with all the other styling that come out of the box (and the great component library).
Note that you don't need a beta flag to justify breaking changes. A major version can also contain breaking changes. It's beta for over 5 years. But it's established and currently has over 300,000 weekly downloads. It's maybe time for the first stable relase. Don't worry: Every software has bugs. I think a beta flag will discourage some users/companies from using it. That may affects popularity. It's like never ending early-access/beta or 0.0.12345 version packages on npm. A matter of trust. "Just do it!" -- Shia LaBeouf
Reacted by Adrien Crivelli, Tin Nguyen, Stefan Charsley and Paul
Note that you don't need a beta flag to justify breaking changes. A major version can also contain breaking changes. It's beta for over 5 years. But it's established and currently has over 300,000 weekly downloads. It's maybe time for the first stable relase. Don't worry: Every software has bugs. I think a beta flag will discourage some users/companies from using it. That may affects popularity. It's like never ending early-access/beta or 0.0.12345 version packages on npm. A matter of trust. "Just do it!" -- Shia LaBeouf
As I understood this, the problem is not fear of bugs or breaking changes... but rather the internal definitions of beta/stable within google that prevents a stable release...
One could also argue that you should not be afraid of a label or a definition (beta in this case)... Also a matter of trusting your self. "What's the matter, CIA got you pushing too many pencils?" -- Arnold Schwarzenegger
The layout systems in Web evolved significantly over the past year and using plain CSS often offers simpler and more performant solution. We'll likely not graduate flex-layout from beta.
Flex layout has been in beta for a while. Using the library has runtime performance implications and we’re not feeling confident moving forward with a stable release. With the evolving layout systems in the Web I’d strongly recommend moving to a pure CSS solution.
Thank you @Splaktar for adding those links. Let me add some clarification to them so people don't necessarily get led astray.
While I respect @mgechev tremendously, and understand fully where he's coming from, I think it's important to make a few things clear.
Like any technology choice, this is not a "this or that" situation. Meaning, yes, raw CSS will always be faster compared to a runtime library. However, hundreds or even thousands of lines of CSS creates substantial strain both in network loading and runtime parsing. Often with responsive design using media queries, CSS can explode on this level, and this is an area where Angular Layout really shines. Not to mention that while I respect the intuitive nature of Minko's reasoning, there is no benchmark right now to back up either side (I am not claiming he's wrong or I'm right either). As always, your mileage may vary, and it's worth understanding the very real cost in either path.
CSS is not always the simpler solution, which is exactly why this library exists. Reasoning about Flexbox and CSS Grid for beginners can provide a substantial learning curve, much like Angular itself. This library can't be the best at absolutely everything, so we bias towards providing that great entry-level experience, in addition to responsive tooling. This comes with costs, as mentioned in the first point.
As for a summary recommendation: please understand your use case carefully. If your absolute, number one, immutable priority is performance and ditching dependencies: you can, and always have been able to, use raw CSS. If you want simplicity and powerful media query tooling, use this library. It may remain in beta indefinitely, but that doesn't mean it's useless.
Reacted by Michael Prentice, Andrew-Marks-Trisept, ma3, Johan Faerch, Stefan Charsley, Paul, Carlos Morales, Tomasz Czajka, Peter Sherwood, Balázs Kiss and 1 more
Yup... "Stop Beta" is what just happened unfortunately. This library is now "LTS"/Deprecated :-((( https://medium.com/@caerus.karu/farewell-flex-layout-aaa567023769
For me, this was a great way to simplify UI positioning of DOM elements and responsive media queries.
I'll truly miss this library.
Thanks to all the people behind it! You did an amazing job!
I'll need to re-write a large portion of my UI, I can't say this doesn't look like a good opportunity to switch to React - more popular, less breaking changes...
Leaves a lot of projects in a pretty crazy position with no real replacement. Bootstrap I suppose - although I hate that grid thing it tries to force upon you. And as the article says, there's always tailwind.
I thank the people for their hard work on the project. But I'm also very disappointed in where it leaves people & their projects. The current solutions aren't.
Adding here as this was originally added to a different thread
Hi
I'm looking into the possibility to take on this project and keep it running. I have used this in the past and have written a couple of blog posts on this library and contributed to the project's documentation on several occasions. I see a lot of people being affected by the Angular team's decision to drop this project leaving the community with a lot of modifications to their projects to migrate to something else. If I can keep the project running (with the help and support of this great community) then that's got to be good for everyone (I hope).
The thing is, I can't do this by myself so I will need help from the community, so I would like to know what the community would like to see initially for things like:
SLA for cutting releases*
Addressing security issues*
Addressing bug fixes*
What direction the project takes
Anything else the community feels is good for the project.
What we should be doing more off
What we should be doing less off
These are my top priority items (*)
All suggestions are welcomed and encouraged.
Activity
julianobrasil commentedon Sep 6, 2018
@RichardC64, maybe this comment helps you to figure out the long-term picture: #674 (comment)
Splaktar commentedon Sep 23, 2018
Also seems like a duplicate of #752.
From reading #674, it looks like Angular v8 may be the proper time frame for a possible GA of
@angular/flex-layout. That could be sometime around April 2019 if I'm not mistaken.inthegarage commentedon Oct 23, 2018
With reference to #871 I also find it unusual for a minor version upgrade to require a major upgrade of a subsystem - in this case Typescript. It means we remain - for a while - on a version of Flex which has some bug fixes, but isn't "version 7", but isn't the latest version of "version 6". Can the team also adopt the policy that subsystems are not upgraded except when a major version implemented?
In other words, minor increments should only be for bug fixes.
willyboy commentedon Dec 19, 2018
It's to keep in line with Angular's major versioning. That way you know that Flex layout 7 works with Angular 7, 6 works with 6, etc. I think there's a lot more value by not having to guess at major versions than to stick with purely semantic versioning. I totally see your point though.
RichardC64 commentedon Apr 1, 2019
Response #674 (comment) is one year old!
julianobrasil commentedon Apr 1, 2019
@RichardC64, Ivy hasn't landed yet so IMHO that answer remains valid and up to date. I'm not sure Ivy will be the default renderer before @angular 9.0.0+. Be prepared for some more beta period until... 2020?
jpike88 commentedon Sep 7, 2019
This library has been in 'beta' far far longer than anything else I've ever seen. Doesn't it lose meaning at this point? Why not just make it official?
Splaktar commentedon Sep 7, 2019
@jpike88 because more breaking and likely significant changes are coming before the team is ready to call this project GA.
Users of this project need to understand that. The beta tag accomplishes this.
#674 (comment) has the full explanation that is still relevant today.
takahser commentedon Sep 16, 2019
Although I've read #674 (comment) I 'm starting to believe that this project will never be released.
Also, how is possible to figure out which versions of the other @angular libs this project is compatible with?
CaerusKaru commentedon Sep 16, 2019
This library is major-version aligned with the versions of Angular (v8->v8). We keep it current with all future releases once Angular CDK issues a compatible release (since we depend on them).
As for stable release, if you don’t believe we’ll ever make it there that’s fine. Plenty of people have chosen not to stick around and wait. You have to make the right choices for your project. However, stable release or not, we believe this library provides tremendous value. Not only that, just because you don’t believe we’ll make it doesn’t mean we never will 😄 .
Personally, I’m waiting until the v9 release to restart efforts towards the redesign. Doing so earlier means likely getting crushed by the freight train that is Ivy.
chetankhilosiya commentedon Feb 13, 2020
Now angular v9 is also released with default Ivy. When are you planning to do stable release? I saw the library v9 version updated 7 days ago still in beta.
jpike88 commentedon May 7, 2020
Angular 9 has been out for 3 months now... this library has to be record breaking in how long it has been 'beta' in name only. @CaerusKaru this 'redesign', are there any blueprints, scopes, roadmaps etc etc that can indicate to what degree breakage will occur? Can people expect this library to go stable this year or is it going to continue as is?
CaerusKaru commentedon May 7, 2020
Somehow I doubt that in the history of software, this library sets the record for longest beta, but point taken. The redesign is in #1185, and comments of all types are welcome. It is an enormous departure from the current library, and even with Angular schematics, I doubt it's an easy feat to introduce. Add to that the fact that the framework team has not seen or discussed this new proposal yet.
I can't offer a tangible update at this time, except to say that I share your frustrations. I'm not going to stop pressuring the team to pick this up, but it's difficult given their shifting priorities.
inthegarage commentedon May 9, 2020
@CaerusKaru Why don't you just remove the word "beta" from the release schedule. Beta in my mind is to proffer a piece of software to gain further customer feedback before going live. I know for certain that flex-layout is inside multi-million pound software applications, hardly beta. I don't think anyone would really know or indeed care what is around the corner, even if it is a complete redesign.
10 remaining items
jpike88 commentedon Oct 5, 2020
It's weird because it's a library that works so damn well...
CaerusKaru commentedon Oct 6, 2020
I understand your frustration, no one more than I would love to see as many people use (and benefit from using) Angular Layout. Unfortunately, the factors you've laid out are not enough to sway the project planning for the Angular team.
The "excuse" here is that the Angular team is finite, and its resources finite. My, and our consumers', will is not enough to override this simple fact. I'm sure if 100% of respondents ranked Angular Layout as their number one priority in the annual Angular survey, that might change. Until then, this project remains in beta unless announced otherwise.
Splaktar commentedon Oct 6, 2020
@CrlsMrls that is intended.
And +1 to everything that @CaerusKaru said above.
qortex commentedon Oct 6, 2020
Ok thanks for the clarification. It helps.
Then, what would you advise as a stable replacement for this library?
I've been using it with great success, but I'm open to consider switching to the supported way if it's not suitable for production on the long run.
CrlsMrls commentedon Oct 7, 2020
@CaerusKaru thank you for spending the time with your clarifications. Very appreciated.
Splaktar commentedon Oct 7, 2020
@qortex https://material.angularjs.org/latest/migration#changes-to-layout-features does a pretty good job of breaking this down and was reviewed/approved/published by the Angular team.
I've done this for a few apps now and it basically boils down to
This may also end up being one of the safest ways to move towards the new "Angular Layout" redesign as you would then be free to start using those new APIs when they are stable w/o worrying about having two layout libraries in the app or having conflicting directives.
Heatmanofurioso commentedon Jan 31, 2022
Hi,
It's been over a year since the last response on this thread.
Any possible news, or pressure that can be applied regarding the issue in matter?
Thank you
qortex commentedon Jan 31, 2022
As a feedback, I switched to using Tailwind CSS and it's an absolute bliss. Flex Layout is nice on its own, but with Tailwind you gain the same simplicity, and added value with all the other styling that come out of the box (and the great component library).
infacto commentedon Feb 1, 2022
Note that you don't need a beta flag to justify breaking changes. A major version can also contain breaking changes. It's beta for over 5 years. But it's established and currently has over 300,000 weekly downloads. It's maybe time for the first stable relase. Don't worry: Every software has bugs. I think a beta flag will discourage some users/companies from using it. That may affects popularity. It's like never ending early-access/beta or 0.0.12345 version packages on npm. A matter of trust. "Just do it!" -- Shia LaBeouf
mackelito commentedon Feb 1, 2022
As I understood this, the problem is not fear of bugs or breaking changes... but rather the internal definitions of beta/stable within google that prevents a stable release...
One could also argue that you should not be afraid of a label or a definition (beta in this case)... Also a matter of trusting your self. "What's the matter, CIA got you pushing too many pencils?" -- Arnold Schwarzenegger
Splaktar commentedon Feb 1, 2022
Official statements from Angular DevRel
https://twitter.com/mgechev/status/1450945968359153672
https://twitter.com/mgechev/status/1458823770622230529
CaerusKaru commentedon Feb 1, 2022
Thank you @Splaktar for adding those links. Let me add some clarification to them so people don't necessarily get led astray.
While I respect @mgechev tremendously, and understand fully where he's coming from, I think it's important to make a few things clear.
Like any technology choice, this is not a "this or that" situation. Meaning, yes, raw CSS will always be faster compared to a runtime library. However, hundreds or even thousands of lines of CSS creates substantial strain both in network loading and runtime parsing. Often with responsive design using media queries, CSS can explode on this level, and this is an area where Angular Layout really shines. Not to mention that while I respect the intuitive nature of Minko's reasoning, there is no benchmark right now to back up either side (I am not claiming he's wrong or I'm right either). As always, your mileage may vary, and it's worth understanding the very real cost in either path.
CSS is not always the simpler solution, which is exactly why this library exists. Reasoning about Flexbox and CSS Grid for beginners can provide a substantial learning curve, much like Angular itself. This library can't be the best at absolutely everything, so we bias towards providing that great entry-level experience, in addition to responsive tooling. This comes with costs, as mentioned in the first point.
As for a summary recommendation: please understand your use case carefully. If your absolute, number one, immutable priority is performance and ditching dependencies: you can, and always have been able to, use raw CSS. If you want simplicity and powerful media query tooling, use this library. It may remain in beta indefinitely, but that doesn't mean it's useless.
HarelM commentedon Dec 4, 2022
Yup... "Stop Beta" is what just happened unfortunately. This library is now "LTS"/Deprecated :-(((
https://medium.com/@caerus.karu/farewell-flex-layout-aaa567023769
For me, this was a great way to simplify UI positioning of DOM elements and responsive media queries.
I'll truly miss this library.
Thanks to all the people behind it! You did an amazing job!
I'll need to re-write a large portion of my UI, I can't say this doesn't look like a good opportunity to switch to React - more popular, less breaking changes...
inthegarage commentedon Dec 4, 2022
Leaves a lot of projects in a pretty crazy position with no real replacement. Bootstrap I suppose - although I hate that grid thing it tries to force upon you. And as the article says, there's always tailwind.
I thank the people for their hard work on the project. But I'm also very disappointed in where it leaves people & their projects. The current solutions aren't.
DuncanFaulkner commentedon Dec 4, 2022
Adding here as this was originally added to a different thread
Hi
I'm looking into the possibility to take on this project and keep it running. I have used this in the past and have written a couple of blog posts on this library and contributed to the project's documentation on several occasions. I see a lot of people being affected by the Angular team's decision to drop this project leaving the community with a lot of modifications to their projects to migrate to something else. If I can keep the project running (with the help and support of this great community) then that's got to be good for everyone (I hope).
The thing is, I can't do this by myself so I will need help from the community, so I would like to know what the community would like to see initially for things like:
SLA for cutting releases*
Addressing security issues*
Addressing bug fixes*
What direction the project takes
Anything else the community feels is good for the project.
What we should be doing more off
What we should be doing less off
These are my top priority items (*)
All suggestions are welcomed and encouraged.
Thanks
Duncan
see original thread here
#1426 (comment)