Bug
After having added custom breakpoints, we should be able to use the default breakpoints. In addition, if a DOM element has a style attribute defined, it should be used if no style is enforced by the flex-layout package.
fxLayout, ngStyle and ngClass work with the custom breakpoints, but not with the default breakpoints (_xs_, _sm_, _md_, _lg_, _xl_). In addition, if you define the attributes _style_, and _ngStyle.custom_breakpoint_, once the rules for _custom_breakpoint_ have been activated, _style_ is not applied anymore (as it should be when _custom_breakpoint_ is no longer active).
A Plunker is available here.
Have the directives work as expected and presented in the doc.
Avoid defining the ObservableMedia in each component, and writing all style-related rules with conditions like media.isActive('custom_breakpoint').
Tested with Angular5.0.2 and 5.0.3, on Windows 10, with Typescript 2.3.4 and 2.6.2, using Firefox and Chrome.
Tested with the latest beta of flex-layout.
It looks like the documentation is outdated as noted in #510
Could you please hurry up? It's docs and there is currently no workaround presented
Here's a working example. Took me 5 mins to sort myself out.
In a custom-breakpoints.ts file
import {BreakPoint} from '@angular/flex-layout';
export const PRINT_BREAKPOINTS: BreakPoint[] = [{
alias: 'my.sm',
suffix: 'mySm',
mediaQuery: '(max-width: 1123px)',
overlapping: false
}];
In your module
import {CUSTOM_BREAKPOINTS_PROVIDER_FACTORY, FlexLayoutModule} from '@angular/flex-layout';
...
providers: [
CUSTOM_BREAKPOINTS_PROVIDER_FACTORY(PRINT_BREAKPOINTS, {defaults: true})
]
I saw no docs nor comments, but I guess defaults tells you want to keep the default breakpoints.
When using something like CUSTOM_BREAKPOINTS_PROVIDER_FACTORY(PRINT_BREAKPOINTS, {defaults: true}) in an AOT build, I get the following errors:
ERROR in Error during template compile of 'AppModule'
Function calls are not supported in decorators but 'buildMergedBreakPoints' was called in 'CUSTOM_BREAKPOINTS_PROVIDER_FACTORY'
'CUSTOM_BREAKPOINTS_PROVIDER_FACTORY' calls 'buildMergedBreakPoints'.
It did indeed work to allow me to create some custom breakpoints and still be able to use the default breakpoints, but this error breaks the production build.
Here's an approach that worked for me in JIT and AOT:
providers: [
{
provide: <InjectionToken<BreakPoint[]>>BREAKPOINTS,
useFactory: buildMergedBreakPoints(CustomBreakpoints, {defaults: true, orientations: true})
},
...
]
As an update on this thread, here's where @ThomasBurleson and I are thinking for setting custom breakpoints in a future release:
providers: [
{
provide: BREAKPOINT,
useValue: {...some breakpoint},
multi: true
}
]
and typeof BREAKPOINT === BreakPoint | BreakPoint[]
We would then have a built-in provider that would register all of the new breakpoints seamlessly under the main BREAKPOINTS token on startup. The defaults could then be optionally disabled by doing something like this:
providers: [
{
provide: BREAKPOINTS
useValue: []
}
]
Once we have a better handle on the design, we'll open a PR. But the docs for the current implementation are on hold until then. @Splaktar's solution looks as good as any, and if someone wants to submit a PR for docs on this in the interim, I'd be happy to review.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
As an update on this thread, here's where @ThomasBurleson and I are thinking for setting custom breakpoints in a future release:
and
typeof BREAKPOINT === BreakPoint | BreakPoint[]We would then have a built-in provider that would register all of the new breakpoints seamlessly under the main
BREAKPOINTStoken on startup. The defaults could then be optionally disabled by doing something like this:Once we have a better handle on the design, we'll open a PR. But the docs for the current implementation are on hold until then. @Splaktar's solution looks as good as any, and if someone wants to submit a PR for docs on this in the interim, I'd be happy to review.