Open CaerusKaru opened 1 year ago
We use it in an extremely complex json-schema/ui-schema/formly reactive forms configuration based questionnaire-like form generator because it allows me to individually define things in a single ui-schema. For example:
Json-Schema
{
type: "object",
properties: {
someproperty: {
type: "string"
}
}
}
Ui-schema:
{
scope: "#",
formlyConfig: {
templateOptions: {
fxLayout: "row wrap
}
}
}
{
scope: "#/properties/someproperty",
formlyConfig: {
templateOptions: {
fxFlex: 50,
fxLayoutAlign="end center"
}
}
}
I removed a lot of stuff for the example but you can hopefully see the correlation, I think. Alot of the above stuff is programatically generated from configuration in a mongo database, using a very complex json merging scheme.
Which then applies the necessary css to both the element generated by formly as well as the wrappers formly generates by adding the directives in the formly custom field types:
<div
[fxLayout]="to.fxLayout ?? 'row wrap'"
[fxLayoutAlign]="to.fxLayoutAlign ?? ''"
[fxLayoutGap]="to.fxLayoutGap ?? '1rem grid'"
>
<ng-container *ngFor="let f of field.fieldGroup; trackBy: trackById">
<formly-field [fxFlex]="getFlex(f)" [field]="f"></formly-field>
</ng-container>
</div>
Without this it would be almost impossible because some of the wrappers/parent elements formly generates can't be affected directly without parsing and validating existing classes applied to the elements. And doing some fancy pseduo class css magic that defeats the purpose of being able to apply it with just the json.
This is a bit of an oversimplification but without flex-layout this is going to be EXTREMELY difficult. Not all of the customizations can just be applied via css classes, as both formly and flex-layout use both the class and style attributes on the fly to do their magic and deal with the outer and inner elements where they are applied. Applying the flex css itself wouldn't be super difficult, its what the directives themselves do that makes this work, not just the css.
@DuncanFaulkner I would likely be willing to chip in on maintenance as well. As you can see from the above explanation I have a vested interest in seeing this project continue. I will end up having to write my own directives otherwise, which I will do if I have to, but this is such a great package I would rather continue using it lol!
I’d recommend keeping the goals nice and tight, aka maintenance mode. Only when things break in a way that’s obviously a break should it be put up as a bug fix. People here don’t need flex layout to do anything novel or different from its intended purpose, which should make taking it on very light work
@DuncanFaulkner if you manage to keep this library up to speed with angular versions you are an absolute champ. As a very small startup we are using it widely and do not have the resources for the migration options suggested by the Angular team, so this would be a lifesaver.
Unfortunately we do not have the economy to fund it at the moment, but you will definitely have our appreciation! Hope it works out.
We replaced ~2000 simple usages of flex-layout with following CSS. Kinda hacky, but seems to work.
Thank you all for your feedback and support on this I will try and collate all the information and put something together.
Thank you all for your feedback and support on this I will try and collate all the information and put something together.
@DuncanFaulkner Please consider accepting sponsorship if that helps in your decision.
As for features, nor sure if everyone agrees, but I was hoping this feature would eventually be implemented: #1185 Ofc only if the most common use-cases has an automated migration
Updating the library with new releases of Angular within 2-3 weeks, and just keeping the Directive features, would be a minimal requirement for us to keep using this library.
As for features, nor sure if everyone agrees, but I was hoping this feature would eventually be implemented: #1185 Ofc only if the most common use-cases has an automated migration
Idk, I feel like this would end up creating just as much re-work for people as moving off of the library entirely. I mean, the performance improvements would certainly be attractive, but I wonder if some of that can be achieved with the new Directive Composition API they just rolled out in v15 (which could allow the public API to remain unchanged).
I attempted to migrate to pure css. It is a major, major PITA, and it reminded me why I use flex-layout in the first place! So I am much more happy to stick with a spinoff of flex-layout., and will happily contribute if needed.
Hello i have done a different approach where I replaced the fxlayouts and fxLayoutAlign with CSS Classes and replaced all of the occurences in my code.
I have made a corresponding table to replicate this on other applications and it looks something like this :
<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">
Before | After -- | -- fxLayout="column" | class="flex-col" fxLayout="column" fxLayoutAlign="space-evenly stretch" | class="flex-col space-evenly stretch" fxLayout="column" fxLayoutAlign="space-evenly center" | class="flex-col space-evenly align-center" fxLayout="column" fxLayoutAlign="center space-evenly" | class="flex-col space-evenly justify-center" fxLayout="column" fxLayoutAlign="center stretch" | class="flex-col stretch justify-center" fxLayout="column" fxLayoutAlign="center center" | class="flex-col justify-center align-center" fxLayout="column" fxLayoutAlign="space-around center" | class="flex-col space-around align-center" fxLayout="column" fxLayoutAlign="space-between center" | class="flex-col space-between align-center" fxLayout="column" fxLayoutAlign="start stretch" | class="flex-col start stretch" fxLayout="column" fxLayoutAlign="start start" | class="flex-col start flex-start" | fxLayout="row" | class="flex-row" fxLayout="row" fxLayoutAlign="space-evenly center" | class="flex-row space-evenly align-center" fxLayout="row" fxLayoutAlign="space-evenly stretch" | class="flex-row space-evenly align-stretch" fxlayout="row" fxLayoutAlign="center center" | class="flex-row justify-center align-center" fxLayout="row" fxLayoutAlign="center stretch" | class="flex-row align-center align-stretch" fxLayout="row" fxLayoutAlign="start center" | class="flex-row start align-center" fxLayout="row" fxLayoutAlign="end center" | class="flex-row end align-center" fxLayout="row" fxLayoutAlign="space-between center" | class="flex-row space-between align-center" fxLayout="row wrap" fxLayoutAlign="space-evenly center" | class="flex-row flex-wrap space-evenly align-center" fxLayout="row wrap" fxLayoutAlign="start start" | class="flex-row flex-wrap start flex-start"
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:
This will help us prioritize the guides as they are submitted.