Angular Layout Migration Guides

[CaerusKaru]

In accordance with the announcement in the Medium post about this library's future, this is a tracking issue for requesting assistance in migrating complex usages of Angular Layout.

If you believe that your library falls under this case, you can request (or vote on existing) migration guides to other, supported solutions like Tailwind or Angular CDK.

Please use the +1 reaction wherever applicable, and do not comment +1. Those comments will be ignored/deleted.

I appreciate your patience as we go through this process. Until the campaign is complete, the library will still be actively maintained.

In your request, please include the following details:

• How many usages you have in your application/library
• Which directives/services from this library you are using
• Why it is non-trivial to migrate

This will help us prioritize the guides as they are submitted.

[michaelfaith]

Our layout needs, I feel, are pretty straightforward. We're almost exclusively using the fx directives (e.g. fxLayout, fxFlex, fxLayoutGap, fxLayoutAlign) in our components, along with the breakpoint aliases (e.g. fxFlex.md), and it seems like Tailwind might be a good alternative to migrate to for that. The main issue is that tailwind isn't currently supported for Angular libraries (via ng-packagr). Any advice on how to achieve that in a re-usable way (since it'll be used across our component library) without tailwind?

Also, really sorry to see this close down. Appreciate all your hard work over the years keeping it alive.

[blogcraft]

It's sad to see this library go away when it was clearly very good! 😕

For me I have no idea where to migrate and what would be even the benefits, but I foresee it to be a very big pain. Our app has ~370 Components and counting and ~4700 attributes in the templates (and we have 3 of those apps). We heavily use fxLayout (cloumn, rows and wraps), fxLayoutGap, fxFlex (with breakpoints and calc), fxFlexFill, fxLayoutAlign, ngClass.*, fxHide and show mostly...

But Thanks a lot @CaerusKaru for all your time and dedication maintaining this library. It has been extremely helpful!

[jnfaerch]

Sad to see this project close own :(

We are using flex-layout heavily in one big and several smaller apps. I hope Tailwind can be a replacement but right now I have no overview of this.

We use this library in our large app ~1.200 times Breakpoints heavily used all through the app These are the main directives we use fxLayout fxLayoutGap fxLayoutAlign fxFlex fxFlexFill fxHide fxShow

Thank you for your work on this library and thank you for the planned transition/shut-down period :+1:

[MikaStark]

So so so so so sad. This project is fantastic, I can't believe it comes to an end... I use this library massively and It will be very hard to something else. I almost use all fxFlex and fxLayout features.

I'm not very okay with using tailwind, I hope someone would like to continue to maintain flex layout.

Anyway thanks for everything @CaerusKaru, the job you have done so far is great :)

[ianvink]

We have a huge app with about 900 directives from this project. Mostly these directives:

• fxLayout
• fxLayoutGap
• fxLayoutAlign
• fxFlex
• fxFlexFill
• fxHide
• fxShow We also have use of many break points like fxFlex.md etc

[Interscope19]

I know that the angular team have their thoughts about the web standar but this library offers more than just alternative for css , it makes the flex and grid hell( joke) more easy to implement and it provides some directives for breakpoints i mean, its a bit agressive to declare a library -that is commonly used for a bunch of teams in their productions projects- as deprecated, i think that we can keep those directives and other stuff that the library offers ( breakpoints and declarative simplicity on flex grid) and incorporate as default in the framework, that can give angular more unique identity instead to make it more like react.

[blogcraft]

I started giving (unwillingly) a try to Tailwind CSS. And I was quite surprised as it is not a bad experience at all.

I found a guide here to help migrate from Flex Layout to Tailwind and it's pretty straight forward.

Also, for people using VS Code I recommend getting the Tailwind CSS IntelliSense extension. It is quite useful.

---

In a nutshell it is this:

Angular Flex-Layout directives | Tailwind Equivalent CSS classes -- | -- `fxLayout=” ”` | Use [`flex-`](https://tailwindcss.com/docs/flex-direction) [`flex-`](https://tailwindcss.com/docs/flex-wrap) classes `fxLayoutAlign=” ”` | Use [`justify-`](https://tailwindcss.com/docs/justify-content) [`items-`](https://tailwindcss.com/docs/align-items) [`content-`](https://tailwindcss.com/docs/align-content) classes `fxLayoutGap=”% \| px \| vw \| vh”` | Use [`gap`](https://tailwindcss.com/docs/gap) on flex items `fxFlex=”” \| px \| % \| vw \| vh \| \| ` | Use [`flex`](https://tailwindcss.com/docs/flex), [`grow`](https://tailwindcss.com/docs/flex-grow), and [`shrink`](https://tailwindcss.com/docs/flex-shrink) classes along with customflex-basis classes overriding *tailwind config* `fxFlexOrder=”int”` | Use [Order](https://tailwindcss.com/docs/order) classes along with custom classesoverriding *tailwind config* `fxFlexOffset=”% \| px \| vw \| vh”` | Use [Margin](https://tailwindcss.com/docs/margin) classes `fxFlexAlign=”start \| baseline \| center \| end”` | Use [Align Self](https://tailwindcss.com/docs/align-self) classes `fxFlexFill` and `fxFill` | Use [`w-full`](https://tailwindcss.com/docs/width) and [`h-full`](https://tailwindcss.com/docs/height) classes `fxShow` and `fxHide` | Use [`block`](https://tailwindcss.com/docs/display#block) and [`hidden`](https://tailwindcss.com/docs/display#hidden) classes Responsive API | [Override Tailwind’s default breakpoints](https://tailwindcss.com/docs/breakpoints#custom-media-queries) to matchwith Angular Flex-Layout. For example,`theme: {extend: {screens: {‘sm’: { ‘min’: ‘600px’, ‘max’: ‘959px’ },‘lt-sm’: { ‘max’: ‘599px’ }….},}}` **I personally I didn't need to do this.** `[ngClass.xs]=”{‘first’:false, ‘third’:true}”` | Use aforementioned responsive APIclass=”gt-xs:first xs:third” `[ngStyle.sm]=”{‘font-size’: ’16px’}”` | Use custom CSS classes as mentioned above. `` | Use custom CSS classes as mentioned above. `gdAreas.xs=”header header \| sidebar content”` | Tailwind does not have a support forgrid-template-areas so we have to use grid columnsand then apply [`Grid Row Start/End`](https://tailwindcss.com/docs/grid-row) or [`Grid Column Start/End`](https://tailwindcss.com/docs/grid-column) classes on grid items.For example, `xs:grid-cols-2` `xs:grid-rows-2` `gdAlignColumns=” ”` | Use [Align Items](https://tailwindcss.com/docs/align-items) and [Align Content](https://tailwindcss.com/docs/align-content) classes `gdAlignRows=” ”` | Use [Place Content](https://tailwindcss.com/docs/place-content) and [Place Items](https://tailwindcss.com/docs/place-items) and Place Items classes `gdAuto` | Use [Grid Auto Flow](https://tailwindcss.com/docs/grid-auto-flow) classes `gdColumns` | Use [Grid Template Columns](https://tailwindcss.com/docs/grid-template-columns) classes along with customclasses overriding *tailwind config* `gdRows` | Use [Grid Template Rows](https://tailwindcss.com/docs/grid-template-rows) classes along with customclasses overriding *tailwind config* `gdGap` | Use [Gap](https://tailwindcss.com/docs/gap) classes along with custom classesoverriding *tailwind config*

[coreConvention]

Just now seeing this. This is upsetting news to say the least. I built an entire JsonSchema/ui-schema based platform around angular flex for one of the biggest hospital chains in the country, which only works because of the way angular flex works (using the directives). There really is no alternative that I am aware of.

Have you all considered handing the project off to the community to maintain? Or is the issue some necessary collaboration with the angular team?

[MikaStark]

Using tailwind is pointless to me. I personally prefer to write few css lines eventually coupled with CDK layout API than over weight my project with a css framework built for people unable to actually write CSS by themself.

I agree with the previous post, if this lib should be maintained by the community it would be fantastic

[anisabboud]

I've successfully migrated from flex-layout (~200 usages) to CSS Flexbox + CSS Grid + Angular CDK layout (without Tailwind).

Here are the replacements I made, in case they are helpful to others.

fxLayout="row", fxLayout="col"

<div fxLayout="row"> → <div class="flex-row">. Global CSS:

// Flex row/col + grid.
.flex-row { display: flex; flex-direction: row; }
.flex-col { display: flex; flex-direction: column; }
.grid { display: grid; }

// Flex-wrap utils.
.flex-wrap { flex-wrap: wrap; }  // Mostly used with flex-row, when wrapping is desired.
.flex-col-xs { @media screen and (max-width: 599px) { flex-direction: column; } }  // Switch from flex-row to flex-col on mobile.

fxLayoutGap

<div fxLayoutGap="8px"> → <div class="gap-8">. Global CSS for common gaps (& inline CSS for uncommon gaps):

// Gap.
.gap-4 { gap: 4px; }
.gap-8 { gap: 8px; }
.gap-10 { gap: 10px; }
.gap-12 { gap: 12px; }
.gap-16 { gap: 16px; }

fxLayoutAlign

<div fxLayoutAlign="justify-between center"> → <div class="space-between items-center">. Global CSS for common alignments (& inline CSS for uncommon ones):

// Justify content.
.space-between { justify-content: space-between; }  // Used very often with flex-row.
.justify-center { justify-content: center; }  // Used to center something via flexbox.

// Align items. (Naming inspiration: https://tailwindcss.com/docs/align-items.)
.items-center { align-items: center; }  // Used very often with flex-row.

fxFlex

<div fxFlex> → <div class="flex-1">. Global CSS for common flex values (& inline CSS for uncommon values like flex-basis):

// Flex/grow/shrink properties https://developer.mozilla.org/en-US/docs/Web/CSS/flex.
.flex-1 { flex: 1 }  // Same as flex: 1 1 0 (grow, shrink, basis 0). Has similar effect to width: 100%;
.flex-grow { flex-grow: 1; }  // Same as flex: 1 1 auto (grow, shrink, basis auto). For spacer, etc. 

fxHide, fxShow

<div fxHide.xs> → <div class="hide-xs">. Global CSS for common hide breakpoints (depending on your app):

// Hide & show for different breakpoints.
.hide-xs    { @media screen and (max-width: 599px) { display: none; } }  // Hide on mobile.
.hide-gt-xs { @media screen and (min-width: 600px) { display: none; } }  // Show only on mobile. Hide on desktop.
.hide-sm    { @media screen and (max-width: 959px) { display: none; } }  // Hide on mobile/tablet.
.hide-gt-sm { @media screen and (min-width: 960px) { display: none; } }  // Show only on mobile/tablet. Hide on desktop.

gdColumns

<div gdColumns="XYZ" gdGap="8px"> → <div class="grid gap-8" style="grid-template-columns: XYZ">. I.e., re-using grid & gap classes from above, and using inline style for grid-template-columns.

ngStyle.xs, ngClass.xs

These are the most challenging to replace - they're one of the nicest features of the flex-layout library. I didn't find a straight-forward replacement. I just replaced them with custom CSS classes & breakpoints in the CSS file. For example, <div style="width: 100px" ngStyle.xs="width: 50px"> → <div class="my-div"> + CSS below

.my-div {
  width: 100px;
  @media screen and (max-width: 599px) {
    width: 50px;  // Smaller on mobile.
  }
}

Note to avoid confusion: Angular's own ngStyle & ngClass are not deprecated. Only the flex-layout extension of these (ngStyle.breakpoint & ngClass.breakpoint) is deprecated.

MediaObserver

Replaced with Angular CDK Layout's BreakpointObserver (which felt faster to me in run-time). Before:

const isMobile: Observable<boolean> = this.mediaObserver.asObservable().pipe(
  map((changes: MediaChange[]) => changes.some(change => change.mqAlias === 'xs')));

After:

const isMobile: Observable<boolean> = this.breakpointObserver.observe(Breakpoints.XSmall).pipe(
  map(state => state.matches));

[michaelfaith]

@anisabboud this is great. Thanks. Just a note though, ngStyle and ngClass are not part of flex-layout, and won't be affected by its retirement. They're part of angular core.

[Interscope19]

@anisabboud this is great. Thanks. Just a note though, ngStyle and ngClass are not part of flex-layout, and won't be affected by its retirement. They're part of angular core.

i think that he talk about de .sm .xs after the ngStyle or ngClass

[michaelfaith]

Ah, gotcha. Fair enough

[anisabboud]

Indeed, I was referring to ngStyle.xs & ngClass.xs, etc. (with breakpoints). But it's an important clarification to make to avoid confusing others, so I updated my post, thanks @michaelfaith!

[sourav-bhar]

Really sad and disappointed to see this library be deprecated. Like many others here, we have used and depended on flex-layout heavily over the years and it's a core part of every component we have ever written.

I see migrating all of that to other alternatives like Tailwind to be a huge, non-trivial, undertaking.

This was a great library and we're truly grateful to all the maintainers who have done such a wonderful job over the years. Please consider handing it over to the community instead of a complete deprecation.

Here is our usage statistics:

We are using flex-layout heavily across 4 production apps. We mainly use the flex-layout directives with breakpoints in all the apps.

Total usage statistics: 7,309 times across 352 components

Here's the breakdown by directive: fxFlex – 3,625 times across 352 components fxLayout – 3,586 times across 351 components fxLayoutGap – 909 times across 283 components fxLayoutAlign – 1,346 times across 350 components fxFlexFill – 6 times in 5 components fxHide, fxShow – 57 times across 32 components

[BryanYin]

By reading Angular blog, I found this issue. We have been using this lib for years and it works really good, thank you for your efforts to support it for such a long time! But it's really sad this lib is going to the end of its lifecycle. We are heavily using below directives with different breakpoints: fxFlex fxLayout fxLayoutAlign fxLayoutGap

I agree with @coreConvention's comments above, please consider hand over this project to the community.

[aceArt-GmbH]

<div fxFlex> → <div class="flex-1">.

@anisabboud I had a similar idea. But adding fxFlex does add style properties to the parent element as well and not just the elment itself.

<div>
    <div>
        test 1
        <div fxFlex>test 2</div>
    </div>
</div>
<div>
    <div>
        test 1
        <div class="flex-1">test 2</div>
    </div>
</div>

is not the same thing. Using the new :has() selector should work however

[ginxdroid]

What about using Bootstrap's grid system + angular material components? (Only bootstrap grid and not other ones like ui components of bootstrap)

[ginxdroid]

Please consider handing over this project to the community. This project is so good. What I liked about using this:

We can use directives instead of classes. That is in other libraries we have to use multiple classes altogether but if we use this one then there is no need to use multiple classes in single class attribute.

Directives makes code easy to maintain and understand since different directives handle different things. e.g if we use bootstrap grid system then code will look like: class="col-12 col-md-6 <our other classes>" but if we use this library then: fxFlex="100%" fxFlex.gt-sm="50%"

(It is not full code ofcourse it is just an example.)

which makes code easy to understand since class attribute is less bloated.

[ginxdroid]

Maybe consider taking votes from community before halting this project. There are many production applications which are using this great library in their templates for building layouts.

[CaerusKaru]

First and foremost, thank you to everyone who has so far shared a solution that has worked for them. This kind of upstreaming and knowledge sharing is crucial to a smooth transition, and is a benefit to all. Sincerely, thank you.

Second, in response to a few comments about "handing off to the community": I am totally ok with anyone forking this package under a new namespace and maintaining something supported the community can move to. If the support story is truly solid, I'm also more than happy to endorse the "official" successor. I do want to make clear, though, that we did search for an appropriate community sponsor of the project prior to the sunsetting of this repo. Unfortunately, no one we talked to really felt it was in their primary domain/expertise to maintain, and so here we are. The project cannot continue under the Angular namespace, and therefore its current NPM package name, because the credentials for publishing must remain tightly controlled by the Angular team. This, along with the unofficial "supported by Angular" moniker the namespace gives the library. But if someone wants to setup, for instance ngx-layout or the like, you are more than welcome.

In the meantime, please keep adding migration stories here. When we get closer to the beginning/middle of LTS, I will start publishing guides/blogs, collated from the cases here (along with some harder cases without easy solutions).

[ginxdroid]

I experienced follwing problems while migrating to other libraries: 1) Migrating to Bootstrap grid = bloated class attribute 2) Migrating to Tailwind css = same, bloated class attribute 3) Writing your own classes = difficult to maintain when application grows larger and difficult to understand 'quickly' for other devs who are working on the same project.

Main speciality of this library: We can use directives instead of classes which will make class attribute less bloated.

I will not prefer writing different attribute values in the same attribute in template because it is not an easy thing to understand especially when building responsive user interface as class attribute grows larger and larger........ e.g. class="col-xs-12 col-sm-8 col-md-6 col-lg-4 <other -class-1> <other -class-2> <other -class-3>"

Bloating bloating and bloating.....

Now consider this: class="<other -class-1> <other -class-2> <other -class-3>" fxFlex.xs="100%" fxFlex.sm="80%" fxFlex.md="50%" fxFlex="33%

which bloats class attribute less than the above example.

This is what I liked about this library. When there is complex layout ui then those separate directives makes code easy to understand and fix.

That is if there is something wrong in mobile device layout then we only need to focus and fix fxFlex.xs directive and not others.

[jpike88]

All I can say is wow.

The entire purpose of this library was to prevent the need to pollute elements with css classes. It serves that purpose extremely well, increasing readability and preventing the code from descending into css hell, falling back to CSS when absolutely necessary.

If the Angular team knew what was good they'd put in the small amount effort to keep it as a part of their toolkit, or even integrate it into the CDK itself. It's like second nature to use in an Angular project, very disappointing news really.

There is no other library I know of that works in this way using directives, and the utility is too good to lose. I'll happily join an unofficial fork to keep it up to speed, and probably like many others, have no intention of dropping it for my various projects.

[ginxdroid]

I am totally agree with you @jpike88 .

[ginxdroid]

A library which has 300k downloads per week is going to halt with just a single Medium post!!!! What the hell........ I am pretty frustrated and sad.

[arambazamba]

I've successfully migrated from flex-layout (~200 usages) to CSS Flexbox + CSS Grid + Angular CDK layout (without Tailwind).

Here are the replacements I made, in case they are helpful to others.

fxLayout="row", fxLayout="col"

<div fxLayout="row"> → <div class="flex-row">. Global CSS:

// Flex row/col + grid.
.flex-row { display: flex; flex-direction: row; }
.flex-col { display: flex; flex-direction: column; }
.grid { display: grid; }

// Flex-wrap utils.
.flex-wrap { flex-wrap: wrap; }  // Mostly used with flex-row, when wrapping is desired.
.flex-col-xs { @media screen and (max-width: 599px) { flex-direction: column; } }  // Switch from flex-row to flex-col on mobile.

fxLayoutGap

<div fxLayoutGap="8px"> → <div class="gap-8">. Global CSS for common gaps (& inline CSS for uncommon gaps):

// Gap.
.gap-4 { gap: 4px; }
.gap-8 { gap: 8px; }
.gap-10 { gap: 10px; }
.gap-12 { gap: 12px; }
.gap-16 { gap: 16px; }

fxLayoutAlign

<div fxLayoutAlign="justify-between center"> → <div class="space-between items-center">. Global CSS for common alignments (& inline CSS for uncommon ones):

// Justify content.
.space-between { justify-content: space-between; }  // Used very often with flex-row.
.justify-center { justify-content: center; }  // Used to center something via flexbox.

// Align items. (Naming inspiration: https://tailwindcss.com/docs/align-items.)
.items-center { align-items: center; }  // Used very often with flex-row.

fxFlex

<div fxFlex> → <div class="flex-1">. Global CSS for common flex values (& inline CSS for uncommon values like flex-basis):

// Flex/grow/shrink properties https://developer.mozilla.org/en-US/docs/Web/CSS/flex.
.flex-1 { flex: 1 }  // Same as flex: 1 1 0 (grow, shrink, basis 0). Has similar effect to width: 100%;
.flex-grow { flex-grow: 1; }  // Same as flex: 1 1 auto (grow, shrink, basis auto). For spacer, etc. 

fxHide, fxShow

<div fxHide.xs> → <div class="hide-xs">. Global CSS for common hide breakpoints (depending on your app):

// Hide & show for different breakpoints.
.hide-xs    { @media screen and (max-width: 599px) { display: none; } }  // Hide on mobile.
.hide-gt-xs { @media screen and (min-width: 600px) { display: none; } }  // Show only on mobile. Hide on desktop.
.hide-sm    { @media screen and (max-width: 959px) { display: none; } }  // Hide on mobile/tablet.
.hide-gt-sm { @media screen and (min-width: 960px) { display: none; } }  // Show only on mobile/tablet. Hide on desktop.

gdColumns

<div gdColumns="XYZ" gdGap="8px"> → <div class="grid gap-8" style="grid-template-columns: XYZ">. I.e., re-using grid & gap classes from above, and using inline style for grid-template-columns.

ngStyle.xs, ngClass.xs

These are the most challenging to replace - they're one of the nicest features of the flex-layout library. I didn't find a straight-forward replacement. I just replaced them with custom CSS classes & breakpoints in the CSS file. For example, <div style="width: 100px" ngStyle.xs="width: 50px"> → <div class="my-div"> + CSS below

.my-div {
  width: 100px;
  @media screen and (max-width: 599px) {
    width: 50px;  // Smaller on mobile.
  }
}

Note to avoid confusion: Angular's own ngStyle & ngClass are not deprecated. Only the flex-layout extension of these (ngStyle.breakpoint & ngClass.breakpoint) is deprecated.

MediaObserver

Replaced with Angular CDK Layout's BreakpointObserver (which felt faster to me in run-time). Before:

const isMobile: Observable<boolean> = this.mediaObserver.asObservable().pipe(
  map((changes: MediaChange[]) => changes.some(change => change.mqAlias === 'xs')));

After:

const isMobile: Observable<boolean> = this.breakpointObserver.observe(Breakpoints.XSmall).pipe(
  map(state => state.matches));

👍 Actually one could go one step further and create directives out of this … most samples for the new directives composition api just combine styles 😜

[michaelfaith]

@CaerusKaru just to clarify, v15 will be the final version of flex-layout right? That was my read of the medium article, and it seems like a lot of folks'.

[ianvink]

Does anyone have a small set of Directives which will do the very basics, like the ones below. I feel that if there was it would solve the majority of uses and provide tremendous value to the community.

fxLayout fxLayoutGap fxLayoutAlign fxFlex fxFlexFill fxHide fxShow

[stevebor1]

I recently converted our large government focused app from angular/bootstrap to angular/material/flex-layout, as we made the decision to stick with core technologies and offerings as they would be more stable. 😔......

We heavily use the standard fxLayout/fxFlex as well as all breakpoints to simplify and standardize development across a responsive application. We've been waiting on 'density' to be finally supported in components, and now that it is in 15, we were ready to upgrade. Now this.

[EduardoMiguel2109]

why not create a simple library that maps the directives to the css in the element? I was thinking of doing it this way to avoid changes to existing code. Before the project dies, you could do one last release with this css mapping

[azimuthdeveloper]

There's a lot wrong here.

First, community engagement: There are over 350k weekly downloads of this package.

In a month, that's over a million downloads of Angular Layout. Now, these people pay nothing for Angular Layout, but I guess they also pay nothing for the entire Angular toolset. Despite these millions of downloads and significant community usage of Angular Layout, this conversation took place within the Angular team. With such significant and extended use by the community, deciding the fate of a critical piece of Angular that so many people used, without engaging the community, is simply the wrong thing to do. Could we, the community, have the option to pay into something, like a Patreon or something, to continue the development of this critical piece of Angular?

Secondly, killing something that works: This lends itself, quite unfortunately, to an affliction that Google-related products seem to suffer from disproportionately. Namely - "This thing is working well and is in use by a lot of people. Let's kill it". Angular v15,v16,v17, and beyond may be high-quality and genuinely beautiful pieces of software. But there are a lot of people out there that don't know that flex-layout has been deprecated, and when they try to move to the next version of Angular, their first warning will be the package failing in the ng update step. I won't remember the improvements to the rendering engine, or that my page views are 0.2 seconds faster. I will care that a package in my packages.json has been deprecated and there is no replacement, forcing me to either stick with the old version of Angular or refactor my entire application.

Finally, undermining confidence in Angular as a whole: Removing widely used packages from mainline support undermines and reduces the confidence that developers can have in Angular as a whole. Should we expect Angular Material to be spontaneously deprecated next week? And if not, why not? Flex layout has 350k downloads a week, Angular material only has three times that. It's not off by some order of magnitude. I suppose we could say that flex layout is "just a layout library". Could we not just say "Angular Material is just a look and feel library, we're dropping it as well, refactor your code to Materialize.css"? It would be nice to be assured that other highly-used pieces of Angular will be around this time next month.

Also, small nitpick. The linked article, entitled "Farewell, Flex Layout" is 3/4 of the author telling a fond recollection of bygone eras, and cute memories they have of the Angular team. Then it abruptly turns to "Angular Flex Layout is going away. Nothing is available to replace it byeeeeeeeeeee". This isn't a good deprecation article. A good deprecation article would have the headings "What is happening?" "What does this mean for you?" "What are your migration options?". Such an article, written so light-heartedly with no real answers or help for the developer, is so bad that it borders on the offensive.

I'm an avid Angular developer, and I sincerely hope that the incorrect decision to deprecate this library is reversed, and flex-layout is instead brought into the main Angular tooling. If not, I hope the article is updated with information that developers can actually use. And still, if both of those things don't come to pass, I genuinely hope that this is a flash in a pan and not a sign of things to expect from Angular moving forward. Because, at this point, if Angular Material got deprecated as well next year, I could only blame myself if I was surprised.

[michaelfaith]

@azimuthdeveloper I generally agree with your sentiments. However

This isn't a good deprecation article.

That wasn't the official deprecation article from the Angular team. This was. That was @CaerusKaru's farewell.

[CaerusKaru]

@azimuthdeveloper I empathize with a lot of your points. The reality, though, is that a) we did consult the community; and b) Google is unfortunately not transactional. What do I mean by this: we asked some well-established actors in the community to take over the project; they declined. I've mentioned earlier in this issue that if another community member wanted to take on this project, they are welcome to do so, but the namespace cannot be reused. Which brings us to the second point, which is that unfortunately no amount of money (short of paying a full Google employee salary) will fund this to stay in the same namespace, because at the end of the day, Google would be responsible, and that's something the team cannot afford. I believe we all like to think sometimes that Google does these things out of spite, or that they make the wrong investments/decisions on products we really like, but at the end of the day, we aren't the ones looking at the balance sheets and paying for developer time.

In our last release, which will fully support v15, we will unpin our peer dependencies, meaning that ng update should not be blocked in the future. This does not mean every future version will work with the last published version of this library, namely if there are APF or other breaking changes, but in the best case it should maintain compatibility otherwise. We hope to get this version out this coming week.

I understand your frustration, and those of the other users here, but I would like to remind everyone the primary goal of this issue is to track meaningful and impactful migration guides that would ease this transition. I am fully committed to authoring those guides depending on feedback, but the complexity of the library is such that it's really hard to understand where the priority is without it. For instance, and this was written about above, it would be trivial to migrate some of the simpler directive-based usage, but really complex to migrate inter-connected directive usage, print, etc. If there is no demand for that, though, we can focus on really nice simple utilities for migration.

As @michaelfaith mentioned, my Medium post was a "how we got here" kind of post, to explain the situation to users otherwise caught unawares of the "why". I understand you would like more information about how to transition, which is 100% why this issue exists. And as Michael otherwise mentioned, there is another article with a brief explainer of alternatives generally available in the meantime.

[azimuthdeveloper]

which is that unfortunately no amount of money (short of paying a full Google employee salary) will fund this to stay in the same namespace, because at the end of the day, Google would be responsible, and that's something the team cannot afford.

If the Angular team, or the people funding the Angular team, can't afford to maintain a widely used package like this (one that the deprecation of is going to cause literally thousands of man-hours of development work to refactor away from) then that is deeply concerning for the future of Angular as a whole. Why? Because it sounds like more of a financial decision than a "What's best for Angular and Angular developers decision". You can unpin dependencies etc, but won't this just simply lead to the atrophy of Angular Layout and increased breakages/incompatibilities over time? As you say, it won't guarantee compatibility forever, which is totally understandable (even in the v14 to v15 migration guide, there are nineteen steps to migrate from an Angular Material v14 app to an Angular Material v15 app. It's easy to imagine how one of these changes, possibly even as soon as v15 to v16, would cause a breaking change that nobody would be able to fix. And because of unpinned dependencies, that's going to culminate in the Angular compiler just throwing up and dumping errors of hard-to-read/hard-to-debug problems, possibly without the developer knowing exactly what has gone wrong. Or worse still, CSS weirdness with no obvious console output).

I understand your frustration, and those of the other users here, but I would like to remind everyone the primary goal of this issue is to track meaningful and impactful migration guides that would ease this transition. I am fully committed to authoring those guides depending on feedback, but the complexity of the library is such that it's really hard to understand where the priority is without it.

To write a migration guide, for even basic apps, I would suggest would be an extremely difficult and lengthy process. Extending that process by adding in how many corner cases and specialized layout needs developers would have, it's hard to see how such a task could have a meaningful outcome. Plus, even if there was an incredible migration guide, many Angular developers work against tightly defined sprints and deadlines and don't have an extra couple of months to refactor away from flex-layout.

Anyway - the decision has been made, so agitating on the particulars of that decision is fruitless (and I'm also probably aggravating someone who has given a lot of time to flex-layout, which seems counter-intuitive as well). It just seems like a genuinely good solution is being dropped for fiscal reasons, which makes me wonder what part of Angular would be dropped next for the same reason. That spooks me.

Thanks for all your hard work on flex-layout. I hope it wasn't all for nothing, and in some way, it survives into the future. I'm also sorry for taking the issue offtopic, it's just surprising (and unpleasant) that there's a huge refactor coming, to get the apps I maintain to look the same as they do today.

EDIT: Just to round this out, according to the Angular release schedule, we can expect a stable release of Angular every 6 months. Angular 15 was released in November 2022, so by May 2023, we should be welcoming Angular 16, and the end of official support for flex-layout. At this point in time, because no tests are being run against flex-layout, and it has unpinned dependencies, we can expect our apps to stop compiling, or the layouts to become totally wrong after we have upgraded to Angular 16. This is about when several developers will notice that something is up. So, in reality, we have five months from now to refactor away from flex-layout, if we would like to take Angular 16 when that lands.

To quote the Angular release page, under "Angular versioning and releases", it says there: "We recognize that you need stability from the Angular framework. Stability ensures that reusable components and libraries, tutorials, tools, and learned practices don't become obsolete unexpectedly. Stability is essential for the ecosystem around Angular to thrive."

A package within the Angular namespace being deprecated like this, and only really being supported until Angular 16 lands (which should happen in roughly five months), to me, is proof that the Angular team is really not living up to what they write on their release page. Literally, an Angular-exclusive package, published within the Angular namespace, tooling which can only be used for Angular, is being deprecated. This is the definition of learned practices becoming obsolete unexpectedly.

@jpike88 talks about the "damage of trust" between the angular brand and the devs who use the library. That's absolutely correct and should occur when the people in the Angular core team can't adhere to the things they write on the release page. How can anyone be sure that specific knowledge they have about Angular Material won't become obsolete when the next major version of Angular lands? We can't. And that's a problem.

Obviously, and I want to really strain this point, I sincerely appreciate everyone's hard work on flex-layout, and what I'm saying here is not supposed to reflect negatively on that, or be taken as an affront or be offensive to the Angular team, and certainly not the developers of flex-layout itself. But somehow, the people behind Angular dun goofed and snookered themselves into a corner where they seemingly have no choice but to go against what is written on their release page and make us all wonder if this is the last thing to go. By itself, that is a problem, and it probably should get an answer.

[jpike88]

Notably absent and what personally rubs me the wrong way that is a representative from the Angular team is not taking ownership of this situation, even if it’s for the decommissioning of this library. This is a heavily used key component by many that was under their namespace, and I would have expected better leadership from them here. The unfortunate outcome is the damage of trust between the angular brand and the large amount of devs using this library under the impression that it would be given the attention it deserves.

Thanks for your efforts, this library has been instrumental in making developer onboarding easier and decluttering our styling. Good luck in the future.

[cubidobusinesssolutions]

For basic usage, plain CSS will do (typos included and not exhaustive)

[fxLayout] {
  display: flex;
  box-sizing: border-box;
}
[fxLayout=row] {
  flex-direction: row;
}
[fxLayout='row wrap'] {
  flex-direction: row;
  flex-wrap: wrap;
}
[fxLayout=column] {
  flex-direction: column;
}
[fxLayout='column wrap'] {
  flex-direction: column;
  flex-wrap: wrap;
}

[fxFlex] {
  flex: 1 1 auto;
}

[fxLayoutAlign='start center'] {
  justify-content: flex-start;
  align-items: center;
}
[fxLayoutAlign='start stretch'] {
  justify-content: flex-start;
  align-items: stretch;
}
[fxLayoutAlign='center start'] {
  justify-content: center;
  align-items: flex-start;
}
[fxLayoutAlign='space-between center'] {
  justify-content: space-between;
  align-items: center;
}
[fxLayoutAlign='stretch stretch'] {
  align-content: stretch;
  align-items: stretch;
}
[fxLayoutAlign='stretch center'] {
  align-content: stretch;
  align-items: center;
}

[fxLayoutGap='1rem'] {
  column-gap: 1rem;
}
[fxLayoutGap='1rem grid'] {
  gap: 1rem;
}

[Franweb79]

which is that unfortunately no amount of money (short of paying a full Google employee salary) will fund this to stay in the same namespace, because at the end of the day, Google would be responsible, and that's something the team cannot afford.

If the Angular team, or the people funding the Angular team, can't afford to maintain a widely used package like this (one that the deprecation of is going to cause literally thousands of man-hours of development work to refactor away from) then that is deeply concerning for the future of Angular as a whole. Why? Because it sounds like more of a financial decision than a "What's best for Angular and Angular developers decision". You can unpin dependencies etc, but won't this just simply lead to the atrophy of Angular Layout and increased breakages/incompatibilities over time? As you say, it won't guarantee compatibility forever, which is totally understandable (even in the v14 to v15 migration guide, there are nineteen steps to migrate from an Angular Material v14 app to an Angular Material v15 app. It's easy to imagine how one of these changes, possibly even as soon as v15 to v16, would cause a breaking change that nobody would be able to fix. And because of unpinned dependencies, that's going to culminate in the Angular compiler just throwing up and dumping errors of hard-to-read/hard-to-debug problems, possibly without the developer knowing exactly what has gone wrong. Or worse still, CSS weirdness with no obvious console output).

I understand your frustration, and those of the other users here, but I would like to remind everyone the primary goal of this issue is to track meaningful and impactful migration guides that would ease this transition. I am fully committed to authoring those guides depending on feedback, but the complexity of the library is such that it's really hard to understand where the priority is without it.

To write a migration guide, for even basic apps, I would suggest would be an extremely difficult and lengthy process. Extending that process by adding in how many corner cases and specialized layout needs developers would have, it's hard to see how such a task could have a meaningful outcome. Plus, even if there was an incredible migration guide, many Angular developers work against tightly defined sprints and deadlines and don't have an extra couple of months to refactor away from flex-layout.

Anyway - the decision has been made, so agitating on the particulars of that decision is fruitless (and I'm also probably aggravating someone who has given a lot of time to flex-layout, which seems counter-intuitive as well). It just seems like a genuinely good solution is being dropped for fiscal reasons, which makes me wonder what part of Angular would be dropped next for the same reason. That spooks me.

Thanks for all your hard work on flex-layout. I hope it wasn't all for nothing, and in some way, it survives into the future. I'm also sorry for taking the issue offtopic, it's just surprising (and unpleasant) that there's a huge refactor coming, to get the apps I maintain to look the same as they do today.

EDIT: Just to round this out, according to the Angular release schedule, we can expect a stable release of Angular every 6 months. Angular 15 was released in November 2022, so by May 2023, we should be welcoming Angular 16, and the end of official support for flex-layout. At this point in time, because no tests are being run against flex-layout, and it has unpinned dependencies, we can expect our apps to stop compiling, or the layouts to become totally wrong after we have upgraded to Angular 16. This is about when several developers will notice that something is up. So, in reality, we have five months from now to refactor away from flex-layout, if we would like to take Angular 16 when that lands.

To quote the Angular release page, under "Angular versioning and releases", it says there: "We recognize that you need stability from the Angular framework. Stability ensures that reusable components and libraries, tutorials, tools, and learned practices don't become obsolete unexpectedly. Stability is essential for the ecosystem around Angular to thrive."

A package within the Angular namespace being deprecated like this, and only really being supported until Angular 16 lands (which should happen in roughly five months), to me, is proof that the Angular team is really not living up to what they write on their release page. Literally, an Angular-exclusive package, published within the Angular namespace, tooling which can only be used for Angular, is being deprecated. This is the definition of learned practices becoming obsolete unexpectedly.

@jpike88 talks about the "damage of trust" between the angular brand and the devs who use the library. That's absolutely correct and should occur when the people in the Angular core team can't adhere to the things they write on the release page. How can anyone be sure that specific knowledge they have about Angular Material won't become obsolete when the next major version of Angular lands? We can't. And that's a problem.

Obviously, and I want to really strain this point, I sincerely appreciate everyone's hard work on flex-layout, and what I'm saying here is not supposed to reflect negatively on that, or be taken as an affront or be offensive to the Angular team, and certainly not the developers of flex-layout itself. But somehow, the people behind Angular dun goofed and snookered themselves into a corner where they seemingly have no choice but to go against what is written on their release page and make us all wonder if this is the last thing to go. By itself, that is a problem, and it probably should get an answer.

I can´t agree more. Despite they say it is "allowing the Angular team to focus on high-impact projects that further move Angular into the future", what I see here is a lack of commitment and probably a Google´s lack of wish to hire and pay more developers to maintain it, if the problem is that they have no time or people to do it.

They say angular-flex is experimental and thus it is not under their commitment but I don´t think "giving a year support while users plan for migration" is the exact meaning of reliability and commitment, angular users and their projects want/ need. That is the response an angular team member gave on another issue which she closed for being "too heated" (I don´t know what did you all expect with this decission)-,

It will be the last message I write about it but I wish to stress how unworthy of trust looks like the angular team now wth this decission. Yesterday was the angularJS to angular 2 migration, now is flex-layout, and tomorrow who will know... I feel exactly the opposite they state under their commitments: I feel that Angular is now a framework which can throw your efforts useless unexpectedly. And definitely a framework which gives us these "surprises" can´t be our main dev tool.

[davidmontgom]

I have to say this is an utter failure and I will take responsibility. I have been very careful to not use packages outside of the default core lib rather be it be python and esp angular. I am now even more risk-averse with using third-party apps to the point of never again. The depreciation of the lib and the amount of refactoring I have to do now ranks as the number one fail of package choice over 20 years of development and the margins are not even close. I was fooled and again my fault because I remember thinking there was a strong synergy with the and the app ... almost like angular approved. I was wrong.

[geo242]

I have to say this is an utter failure and I will take responsibility. I have been very careful to not use packages outside of the default core lib rather be it be python and esp angular. I am now even more risk-averse with using third-party apps to the point of never again. The depreciation of the lib and the amount of refactoring I have to do now ranks as the number one fail of package choice over 20 years of development and the margins are not even close. I was fooled and again my fault because I remember thinking there was a strong synergy with the and the app ... almost like angular approved. I was wrong.

I am the same way and now it looks like I really can't trust any package maintainer, even if it's backed by one of the largest corporations on the planet. Does this kind of thing happen with Vue, React, etc.? I am honestly asking since I don't have as much experience with those libraries and communities. I would hope not. And if not, that tells me it's a symptom (as mentioned above) of the Google culture of blowing up widely used products on the regular. I just didn't expect that culture to seep into Angular, but maybe that's me being naive. As many others have stated, this ruins my trust in Angular as a whole and I will start thinking about considering moving to other frameworks in the future.

It would be interested to see if it's possible to somehow quantify the monetary impact this is going to have on the community and companies that will now have to pay developers to do a ton of refactoring (myself and the company I work for included). I would guess we are talking multiple millions of dollars, but I wouldn't know where to start in coming up with that number. I would also guess that many of the companies affected are either one man operations or small businesses that don't have a huge budget and can't easily absorb things like this. But I have to wonder if anyone that was part of this decision even considered that.

[Franweb79]

I have to say this is an utter failure and I will take responsibility. I have been very careful to not use packages outside of the default core lib rather be it be python and esp angular. I am now even more risk-averse with using third-party apps to the point of never again. The depreciation of the lib and the amount of refactoring I have to do now ranks as the number one fail of package choice over 20 years of development and the margins are not even close. I was fooled and again my fault because I remember thinking there was a strong synergy with the and the app ... almost like angular approved. I was wrong.

I am the same way and now it looks like I really can't trust any package maintainer, even if it's backed by one of the largest corporations on the planet. Does this kind of thing happen with Vue, React, etc.? I am honestly asking since I don't have as much experience with those libraries and communities. I would hope not. And if not, that tells me it's a symptom (as mentioned above) of the Google culture of blowing up widely used products on the regular. I just didn't expect that culture to seep into Angular, but maybe that's me being naive. As many others have stated, this ruins my trust in Angular as a whole and I will start thinking about considering moving to other frameworks in the future.

It would be interested to see if it's possible to somehow quantify the monetary impact this is going to have on the community and companies that will now have to pay developers to do a ton of refactoring (myself and the company I work for included). I would guess we are talking multiple millions of dollars, but I wouldn't know where to start in coming up with that number. I would also guess that many of the companies affected are either one man operations or small businesses that don't have a huge budget and can't easily absorb things like this. But I have to wonder if anyone that was part of this decision even considered that.

The real impact of this will come with the release of angular v16, since many devs are not aware of this deprecation and will face a HUGE problem with their proyects when they update. I guess many will prefer even making a new app from scratch with v16 or with another more mature framework. It will be translated into great delays on deadlines, freelances spending sleepless nights to fix this, and big companies maybe hiring devs to solve the migration problems or create new apps. Others maybe will be even fired for having chosen Angular for the project. They will be made responsibles by their angry bosses for what Angular Team made.

Also we have around 5 months until v16 is released; so the TLS year support they gave us are actually 6 months to make all migrations, and counting we have still no clear paths and guides to do that and how many breaking changes we will encounter. For a dev with various Angular projects based on angular flex-layout, this can be just hell and even could affect their health for the amount of unpaid job or extra hours they will have to do.

Has Angular Team thought about all of these things?

As others pointed out, if Google can´t afford the hiring of new devs to maintain a widely used library which is the base of thousands of angular projects, what can be expect in the future? I am now afraid of even using Angular Material.

Maybe it is a good chance, as you pointed out, to get new jobs if we learn how to properly migrate from flex-layout to CSS. You know, every crisis means a chance... But that is not the point.

I won´t leave Angular because that would mean, closing many doors and wasting a lot of years' learning effort; but with all of this I have learned how dangerous is to rely all your efforts to one single framework. I will start learning React and, if it is good enough, will become my primary dev tool, using only Angular when the projects could be made relying on the less libraries possible in a fast way, when I am sure that a decission like this can´t affect my project.

[michaelfaith]

The real impact of this will come with the release of angular v16, since many devs are not aware of this deprecation and will face a HUGE problem with their proyects when they update.

Also we have around 5 months until v16 is released; so the TLS year support they gave us are actually 6 months

They said they're going to unlock the peer dependencies in the new release. So I suspect it'll be >=15 or something like that, rather than ^15.

[aceArt-GmbH]

[fxFlex] { flex: 1 1 auto; }

@cubidobusinesssolutions I had a similar idea. But adding fxFlex does add style properties to the parent element as well and not just the element itself.

<div>
    <div>
        test 1
        <div fxFlex>test 2</div>
    </div>
</div>

<style>
[fxFlex2] {
  flex: 1 1 auto;
}
</style>
<div>
    <div>
        test 3
        <div fxFlex2>test 4</div>
    </div>
</div>

is not the same thing. Or am I wrong here? Using the new :has() selector should work however

[chris-wahl]

If anyone else is like me and have a big (150k+ LOC) app that makes extensive use of this package, here's what I'm doing to help migrate into @media queries from things like fxLayout.gt-xs, etc. Definitely not claiming it's the right solution, but hopefully it helps someone else.

This is a simple-and-much-to-be-desired drop in, but it's quick enough if you need to pull out a couple thousand flex-layout directives that deal with breakpoints.

---

1. Move your global styles.scss into a subdirectory (i.e. move the file to src/styles/styles.scss). I did this a while back to organize my variables, themes, etc, into a number of different scss files, so if you've also done it, just skip to step 2.

Will need to update angular.json to look in this folder, rather than just at the global file by updating the styles and stylePreoprocessorOptions property under your build settings.

    "build": {
        ....
        "styles": [ "src/styles/styles.scss" },
        "stylePreprocessorOptions": {
              "includePaths": [
                "src/styles"
              ]
        }
        ....
    }

---

2. In this styles/ directory, add a breakpoints.scss with the following content:

$xs: 599px;
$sm: 969px;
$md: 1279px;
$lg: 1919px;
$xl: 5000px;

$fx-media-queries: (
  'xs':     "screen and (max-width: #{$xs})",
  'sm':     "screen and (min-width: #{$xs + 1}) and (max-width: #{$sm})",
  "md":     "screen and (min-width: #{$sm + 1}) and (max-width: #{$md})",
  "lg":     'screen and (min-width: #{$md + 1}) and (max-width: #{$lg})',
  "xl":     'screen and (min-width: #{$lg + 1}) and (max-width: #{$xl})',

  "lt-sm":  'screen and (max-width: #{$xs})',
  "lt-md":  'screen and (max-width: #{$sm})',
  "lt-lg":  'screen and (max-width: #{$md})',
  "lt-xl":  'screen and (max-width: #{$lg})',

  "gt-xs":  'screen and (min-width: #{$xs + 1})',
  "gt-sm":  'screen and (min-width: #{$sm + 1})',
  "gt-md":  'screen and (min-width: #{$md + 1})',
  "gt-lg":  'screen and (min-width: #{$lg + 1})',
);

This just stores all the flex-layout breakpoints into a simple map, using the same language ('xs', 'gt-sm', etc.). In the next step, we can grab the query by using map-get with whatever breakpoint descriptor.

---

3. Apply where necessary. For example, if I was using <div fxLayout="row" fxLayout.lt-md="column">...</div> for some component, in that component's local scss file, I'd create a class with:

@import "breakpoints";

.container {
    display: flex;
    flex-direction: row;

    @media #{map-get($fx-media-queries, 'lt-md')} {
        flex-direction: column;
    }
}

and replace the directives with <div class="container">...</div>

Of course, add in your place-content and align-items changes in there as necessary.

I'm absolutely certain this could be wrapped into an even easier @mixin call but I've already used this much in a dozen places and I'm not really in the mood to re-write it. But you can! And should!

---

Edit: Here's a shortcut @mixin that can be slapped into breakpoints.scss:

@mixin breakpoint($bp) {
  @media #{map-get($fx-media-queries, $bp)} {
      @content;
  }
}

and now Sass will compile

.test {
    display: flex;
    flex-direction: row;
    @include breakpoint('lt-md') {
        flex-direction: column;
    };
}

into

.test {
  display: flex;
  flex-direction: row;
}
@media screen and (max-width: 969px) {
  .test {
    flex-direction: column;
  }
}

[aureldussauge]

For basic usage, plain CSS will do (typos included and not exhaustive)

[fxLayout] {
  display: flex;
  box-sizing: border-box;
}
...

Thank you for this answer. Also, don't forget that fxFlex is able to add display: flex on a parent that doesn't have an fxLayout directive. fxLayoutAlign can also add display: flex on its host element even without fxLayout. This should be taken into account for your migration, depending on how you were using flex-layout.

[aureldussauge]

If you choose to migrate to Tailwind CSS, I recommend using important: true in your tailwind.config.js. This property will add !important to every Tailwind style.

This must seem like bad practice to you. However, don't forget that flex-layout adds inline styles, which isn't really any different, since it also prevents to play with CSS specificity.

Also, it is recommended that utility classes, such as those added by tailwind, have a higher CSS importance than component classes.

For a migration in a large application with thousands flex-layout directives, you may have regressions if you don't work like that. For example, if you had a fxLayout="column" on a <mat-card>, it won't work to use class="flex flex-col" because .mat-card has a display: block that has greater specificity than the Tailwind classes.

If you're thinking of using Tailwind's @layer, keep in mind that it only performs a code reorganization and does not prevent a more specific selector from overriding Tailwind styles.

Also, native CSS @layer won't be able to save you either because there is no Angular way to scope styles from libraries into a @layer.

And finally, Adam Wathan, the creator of Tailwind, confirmed that this is a good practice and that Bootstrap works the same way.

You can also use the selector strategy instead by adding important: 'your selector', but it still won't prevent to have a more specific selector.

[born2net]

Angular team drop of flex-layout is disconcerting and we hope the angular team will reconsider.

We have a huge project in Angular 14 with thousands of libraries which is developed by a over dozen developers. We rely heavily on flex-layout, we simply are in shock that the Angular team has decided to drop support for it. We tried to upgrade to Angular v15 and failed due to the lack of support from angular-material. We really hope that through this post and the support of the community the Angular team will reconsider and allow opt-in to flex-layout while supporting it for backwards and forward compatibility, test it for upgrade to v15+ and beyond or allow for a solid migration guide (possibly via CLI).

we use:

fxLayout
fxLayoutGap
fxLayoutAlign
fxFlex
fxFlexFill
fxHide
fxShow

We simply are unsure on how to move forward and we are asking the team and the community for assistance.

Sean.

[DuncanFaulkner]

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:

1. SLA for cutting releases*
2. Addressing security issues*
3. Addressing bug fixes*
4. What direction the project takes
5. Anything else the community feels is good for the project.
6. What we should be doing more off
7. What we should be doing less off

These are my top priority items (*) All suggestions are welcomed and encouraged.

Thanks Duncan

[michaelfaith]

@DuncanFaulkner really appreciate the leadership on this!
With regard to what direction the project should take, it seems like we've gotten a lot of good information in this thread about what aspects of the library people are using most. That could help guide decisions about what to prioritize and/or descope entirely. And from a branding perspective, there was this old issue discussing a possible renaming of the library to reflect that it includes both flex and grid (so possibly just naming it /layout)

[geo242]

@DuncanFaulkner Bravo! I really hope you can take this on!

Here are some opinions regarding the points you mentioned...

1. I would think that matching the Angular release schedule would be a good goal
2. I would like to see the library either be trimmed down to the most used features or split into multiple projects or at least namespaces for well defined feature separations (e.g. grid vs flexbox). But this is not something I feel strongly about, nor should it be forced if it's going to cause a lot of disruption for the current user base.

I don't have much else to add to the other points as I was pretty happy with the cadence of the existing package regarding bugs/security etc.

I am happy to help contribute to the project as well. I have a vested interest in keeping it alive as I have many large projects that depend on it.

[sourav-bhar]

@DuncanFaulkner, I really appreciate your initiative and volunteering to keep this alive. 👏👏

As you have seen from the many dozens of posts, this is a core technology finely integrated into the fabric of thousands of production apps, with no easy migration path that works out of the box. Moreover, this really works, and works well for all those teams ( including ours), so makes little sense to migrate off of it.

The two main requirements, from our end, for this project would be:

• Match the release schedule of Angular (say Angular release + 1-4 weeks, based on capacity)
• Stability of existing features over adding new ones, or deprecating less used ones

I'll not be able to contribute towards maintaining it, but I will definitely consider sponsoring it, if that helps. I hope that you, potentially along with few others, can keep this alive. 🤞