![\"A](\"/blog/ngoptimizedimage-1/placeholder.gif\")
If you've worked on a web app, you know that images significantly impact both design and performance. While\nthey make pages look great, they can also slow everything down. That’s where Angular’s NgOptimizedImage\ndirective comes in. It’s a handy tool for optimizing images, so they load faster without losing quality. Let’s\ndive into how this directive can make your Angular app snappier and improve user experience.
We all want our apps to look good, but images come with costlier load times. Optimizing images can\ndramatically improve performance metrics, especially the\nLargest Contentful Paint (LCP),\nwhich measures how fast the largest piece of content appears on the screen. This is huge for user experience\nand SEO. Angular’s NgOptimizedImage directive makes it easy to get it right without manual tweaks.
NgOptimizedImagesrcSet and sizesThe srcSet and sizes attributes allow the browser to load the right image size for each device, which is\nespecially helpful for performance. The great thing about Angular’s NgOptimizedImage directive is that it\ngenerates the srcSet for you, so you don’t need to do it manually.
Example:
\n<img\n ngSrc=\"angular.jpg\"\n width=\"200\"\n height=\"200\"\n sizes=\"80vw\"\n/>\nHere, sizes=\"80vw\" sets the image to 80% of the viewport width. Angular will handle the rest, creating a\nsrcSet with various resolutions so that each device gets the best fit. This saves time and ensures a smooth\nload no matter the screen size.
If you’re working with specific screen sizes, Angular lets you customize breakpoints by setting an\nIMAGE_CONFIG token. This way, you can pick just the breakpoints that match your app’s design.
Example:
\nproviders: [{\n provide: IMAGE_CONFIG,\n useValue: {\n breakpoints: [384, 640, 750]\n }\n}]\nNow Angular will only generate images for 384px, 640px, and 750px, which keeps your file sizes smaller and\nyour app faster.
\npriorityEver noticed how long it can take to load a big image like a banner? The priority attribute tells Angular\nwhich images are critical for loading first. If you set priority, Angular preloads the image, making sure it\nappears quickly, improving that all-important LCP.
Example:
\n<img\n ngSrc=\"hero.jpg\"\n width=\"1200\"\n height=\"600\"\n priority\n/>\nFor server-side rendered apps, Angular even adds a <link rel=\"preload\"> tag for these images, so they start\nloading right away. This is perfect for hero images or banners that you want users to see immediately.
Need an image to fill a container, like a background? fill mode has you covered. It lets an image scale to\nfit the container without needing fixed dimensions, which is perfect for layouts with unknown widths or\nheights.
Example:
\n<img ngSrc=\"background.jpg\" fill/>\nJust make sure your container has position: relative, absolute, or fixed, so the image fills it\nproperly. This feature is great for responsive layouts where you want images to adapt smoothly.
Angular makes lazy loading effortless with loading=\"lazy\", which defers loading images until they’re about\nto be visible. This reduces the initial page load and is awesome for things like image galleries.
Example:
\n<img\n ngSrc=\"thumbnail.jpg\"\n width=\"200\"\n height=\"200\"\n loading=\"lazy\"\n/>\nJust be cautious with images that are crucial to the layout, like a logo. For these, skip lazy loading to\nensure they load right away.
\nNothing kills user experience like a blank loading image. With placeholder, you can show a temporary low-res\nversion or even a Base64-encoded\npreview while the main image loads. This provides a smoother experience as users see a preview of the\nimage right away.
Here’s an example of implementing a placeholder:
\n<img\n ngSrc=\"profile.jpg\"\n width=\"200\"\n height=\"200\"\n placeholder\n/>\nTo take it a step further, you can use a Base64-encoded image as a placeholder. For example, a blurred\nversion of the image can be used to indicate that the original is still loading.
\n
The placeholder blur effect can be customized with the placeHolderConfig\nobject or turned off entirely. For example:
\n<img\n ngSrc=\"cat.jpg\"\n width=\"400\"\n height=\"200\"\n placeholder\n [placeholderConfig]=\"{blur: false}\"\n/>\nIf you'd like to use a Base64-encoded placeholder, you can easily generate the string using:
\n base64 -i input-image.jpg\nOnce you have the Base64 string, you can embed it directly into your HTML as the src for the placeholder:
\n<img\n ngSrc=\"profile.jpg\"\n width=\"200\"\n height=\"200\"\n placeholder=\"data:image/jpeg;base64,/9j/4AAQSk...\"\n/>\nThis approach makes the user experience smoother and creates a seamless visual flow.
\nIf you use a CDN, you can generate low-res placeholders\nautomatically. Just keep them small (under 4 KB) to avoid slowing down the load. Angular will even throw\nan error if the placeholder size is too big:
\nNG02965: The NgOptimizedImage directive (activated on an <img> element with the ngSrc=\"angular.jpg\") has\ndetected that the placeholder attribute is set to a data URL which is longer than 4000 characters. This\nis discouraged, as large inline placeholders directly increase the bundle size of Angular and hurt page\nload performance. For better loading performance, generate a smaller data URL placeholder.\nBy using a Content Delivery Network (CDN) with NgOptimizedImage, you get faster load times because images\nare served from servers closer to your users. CDNs cache content across the globe, meaning shorter load times\nand less data travel, which makes a huge difference, especially for users far from your primary server.
CDNs also often compress images, ensuring the best quality at the smallest size, which boosts performance even\nfurther. When combined with NgOptimizedImage, CDNs can help you build a fast, responsive app that works well\nfor users everywhere.
Now, let's look at a real-world example to see how the NgOptimizedImage directive can make a big difference\nin performance. Imagine we’re building a site that displays 16 preview images.
![\"Preview](\"/blog/ngoptimizedimage-1/demo-app.png\")
Here’s the initial setup with the standard src attribute:
<div style=\"...\">\n @for (image of list; track $index) {\n <img\n width=\"300\"\n height=\"300\"\n [src]=\"image\"\n alt=\"A 300x300 placeholder image with a light gray background and bold black 'Preview' text in the center\"\n />\n }\n</div>\nWhen we analyze the page in Lighthouse, the First Contentful Paint (FCP) comes in at 1.4 seconds, while the\nLargest Contentful Paint (LCP) lags behind at 13.5 seconds—not ideal.
\n![\"Lighthouse](\"/blog/ngoptimizedimage-1/demo-app-initial-lighthouse-score.png\")
By making a few tweaks with NgOptimizedImage, we can get those numbers way down:
<div style=\"...\">\n @for (image of list; track $index) {\n <img\n width=\"300\"\n height=\"300\"\n [src]=\"image\"\n alt=\"A 300x300 placeholder image with a light gray background and bold black 'Preview' text in the center\"\n priority\n placeholder\n />\n }\n</div>\nTo go the extra mile, we add a preconnect link for our image server in the <head>:
<link rel=\"preconnect\" href=\"https://fpoimg.com/\">\nAnd in our app configuration, we set up\na custom image loader\nfor our CDN (e.g., Imgix):
const appConfig: ApplicationConfig = {\n providers: [provideImgixLoader('https://fpoimg.com/')],\n};\nWith these small adjustments, we see a huge performance boost: FCP drops to just 0.2 seconds, and LCP is down\nto a quick 0.7 seconds! This is a perfect example of how NgOptimizedImage can make a real difference in your\napp’s speed and user experience.
![\"Lighthouse](\"blog/ngoptimizedimage-1/demo-app-final-lighthouse-score.png\")
Angular’s NgOptimizedImage is a fantastic tool for improving image handling and app performance. Whether\nyou’re working with responsive images, lazy loading, or CDN integration, this directive makes it easy to get\nthings right. With these optimizations, you’ll have a faster, smoother app that keeps users happy. Give\nNgOptimizedImage a try and see the difference in your next project!
You can access the application used in the article on\nGitHub.
", "url": "https://devintent.com/blog/2024-11-23-level-up-your-apps-speed-with-ngoptimizedimage.md", "title": "Level Up Your App`s Speed with `NgOptimizedImage`", "summary": "Explore how NgOptimizedImage transforms Angular app performance by optimizing image loading. Get a detailed breakdown of attributes, their usage, and impact. Learn how to achieve a perfect 100 Performance score.", "date_modified": "2024-11-23T14:18:00.000Z", "tags": [ "angular", "perf" ] }, { "id": "blog/2024-08-20-testing-reactive-angular-components.md", "content_html": "In this article, we will take a look at how to test the reactive components in Angular, especially with some\nof the nifty new features that have come along. Our case study involves a component we created for\ndemonstration, UsersComponent. Together, we'll unpack its code and walk through the testing process,\nhighlighting on the why's and how's of each step.
First off, let's chat about our UsersComponent. It's a nifty standalone component designed to handle a user\nlist in a reactive manner, making good use of Angular's reactive features\nlike signal and effect() for\nhandling the data and keep the UI fresh.
@Component({\n standalone: true,\n // Component metadata...\n})\nexport class UsersComponent implements OnInit {\n private readonly usersService = inject(UsersService);\n readonly dataSource: MatTableDataSource<User> =\n new MatTableDataSource<User>([]);\n readonly users: WritableSignal<User[]> = signal([]);\n\n constructor() {\n effect(() => {\n this.dataSource.data = this.users();\n });\n }\n\n async ngOnInit(): Promise<void> {\n this.users.set(await lastValueFrom(this.usersService.getUsers()));\n }\n\n addUser(): void {\n const iter = this.users().length + 1;\n this.users.update(users => [...users, newUser]);\n }\n\n removeUser(id: string): void {\n this.users.update(users => users.filter((user) => user.id !== id));\n }\n}\nThe constructor is where the magic starts. We've got an effect() that set up the stage and ensures the\nMatTableDataSource is always reflecting\nthe latest users' data. It keeps our UI accurately updated, no manual refreshes needed.
When ngOnInit() kicks in, it's all about fetching the async data and\nsetting it up in the users signal. This action gets the ball rolling for the effect to do its thing and\nupdate the UI.
\nWe have also implemented methods to add a new user or take one out. The addUser() and removeUser()\nfunctions tweak the users signal, which also triggers the effect() to update the data source accordingly.
Now, when it comes to testing these reactive Angular pieces, there's a bit of know-how involved. We need to\nunderstand several Angular-specific methods and concepts, along with strategies to avoid calls to the real\nservices. We're tackling TestBed.flushEffects(), the mechanics behind effect(), signal.update(),\nsignal.set() and fixture.whenStable()method, not to mention Jasmine's spyOn to keep our service calls in\ncheck.
The TestBed.flushEffects() method, introduced in\nrecent Angular updates (PR #51049\nand PR #53843), is super important for testing\ncomponents with effects. It ensures that all the queued effects are executed in the test environment. This is\nespecially useful for those asynchronous moments when you want to make sure everything's settled before making\nyour assertions.
\nIn our UsersComponent, we used the power of effect(),\nsignal.update(), and\nsignal.set() to keep things reactive and fresh.
The effect() function allows us to create a reactive link between the users signal and\nthe MatTableDataSource. This means whenever the users signal changes, the effect() function automatically\nupdates dataSource.data, ensuring the UI stays in sync with the state.
signal.set() is our direct line to replace the signal's current value and kick the effect() into gear,\nupdating the data source with the fresh list of users.
signal.set([...users, newUser]);\nAnd for those times when you need to finesse the current signal value, signal.update() is the go-to,\nallowing tweaking the signal's value based on its current state. Perfect for when you want to add a new user\nwithout replacing the whole users list.
signal.update(users => [...users, newUser]);\nAsynchronous operations are the norm when fetching data, we need to ensure that our tests wait for these\noperations to complete. This is\nwhere whenStable() comes into play.
\nawait fixture.whenStable();\nThis function returns a promise that resolves when all pending asynchronous activities within the component\nare completed. It's essential for ensuring that our assertions are made after the component has finished\nprocessing the data.
\nWe definitely don't want our tests making actual calls out to the real services. So, we bring\nin Jasmine's spyOn method to intercept calls to\nthe UsersService.getUsers() method and provide controlled, predictable responses.
beforeEach(() => {\n spyOn(usersService, 'getUsers').and.returnValue(of(mockedUsers));\n...\n});\nBy doing so, we simulate the service's behavior without making actual HTTP requests. This approach ensures\nthat our tests remain fast and are not affected by external factors such as network latency or service\navailability.
\nWe used fixture.detectChanges() to work\nin the beforeEach to get the component's lifecycle\nrolling and make sure ngOnInit does its thing.
beforeEach(() => {\n ...\n fixture.detectChanges();\n});\nThis is essential for setting up the initial state of the component, such as bind properties or fetching the\ninitial list of users and ensures that tests have a consistent starting state, with the component fully\ninitialized and ready to respond to simulated user interactions.
\nArmed with our understanding of Angular's reactive features and testing methods, we're now ready to delve into\nthe unit tests for UsersComponent. Each test case is meticulously crafted to verify the component's\nfunctionality, ensuring it behaves as expected under various scenarios.
\nit('should populate MatTableDataSource with users', async () => {\n expect(component.dataSource.data.length)\n .withContext('Data Source length before fetch').toBe(0);\n\n await fixture.whenStable();\n TestBed.flushEffects();\n\n expect(component.users()).withContext('User list after fetch')\n .toEqual(mockedUsers);\n expect(component.dataSource.data.length)\n .withContext('Data Source length after fetch').toBe(3);\n expect(component.dataSource.data).toEqual(mockedUsers);\n});\nIn this test, we first assert that our data source is initially empty. After calling fixture.whenStable(),\nwe ensure all asynchronous operations have completed. Then, TestBed.flushEffects() is invoked to process any\neffects, such as those linked to our users signal. This guarantees that our UI is synchronized with the\ncurrent state. We conclude by asserting that the data source now contains the mocked users, proving that our\neffects correctly update the UI in response to the signal changes.
it('should add a new user', async () => {\n const newUser = {\n id: 'id_4',\n username: 'user_name_4',\n email: 'test4@email.com'\n }\n\n await fixture.whenStable();\n await component.addUser();\n TestBed.flushEffects();\n\n expect(component.dataSource.data.length)\n .withContext('Data Source length after new user addition').toBe(4);\n expect(component.dataSource.data).toEqual([...mockedUsers, newUser]);\n});\nThis test focuses on adding a new user. We initiate by awaiting component stabilization and then invoke the\nasync addUser() method, which updates the users signal. Post this, TestBed.flushEffects() is called to\ntrigger the effects that update the UI. Our assertions confirm that the data source now includes the new user,\ndemonstrating the component's dynamic response to state changes.
it('should remove user', async () => {\n await fixture.whenStable();\n await component.removeUser('id_2');\n TestBed.flushEffects();\n\n expect(component.dataSource.data.length)\n .withContext('Data Source length after user remove').toBe(2);\n expect(component.dataSource.data[1].id).toBe('id_3');\n});\nIn the final test, we validate the removal of a user. After stabilizing the component, we call removeUser(),\nupdating the users signal. Following this with TestBed.flushEffects() ensures our effects process this\nchange. The assertions then verify that the data source has been updated to reflect the removal of the\nspecified user, again highlighting the reactive nature of our component.
Here's the complete overview of our UsersComponent tests:
\ndescribe('UserListComponent', () => {\n let component: UsersComponent;\n let usersService: UsersService;\n let fixture: ComponentFixture<UsersComponent>;\n const mockedUsers: User[] = [\n {\"id\": \"id_1\", \"username\": \"user_name_1\", \"email\": \"test1@email.com\"},\n {\"id\": \"id_2\", \"username\": \"user_name_2\", \"email\": \"test2@email.com\"},\n {\"id\": \"id_3\", \"username\": \"user_name_3\", \"email\": \"test3@email.com\"}\n ];\n\n beforeEach(async () => {\n await TestBed.configureTestingModule({\n imports: [UsersComponent, NoopAnimationsModule, HttpClientTestingModule],\n providers: [UsersService],\n }).compileComponents();\n\n usersService = TestBed.inject(UsersService);\n fixture = TestBed.createComponent(UsersComponent);\n component = fixture.componentInstance;\n });\n\n beforeEach(() => {\n spyOn(usersService, 'getUsers').and.returnValue(of(mockedUsers));\n fixture.detectChanges();\n });\n\n it('should create', () => {\n expect(component).toBeTruthy();\n });\n\n it('should initialize with default values', () => {\n expect(component.isLoading()).toBeTruthy();\n expect(component.dataSource.data.length).toBe(0);\n expect(component.displayedColumns.length).toBe(4);\n });\n\n it('should populate MatTableDataSource with users', async () => {\n expect(component.dataSource.data.length)\n .withContext('Data Source length before fetch').toBe(0);\n\n await fixture.whenStable();\n TestBed.flushEffects();\n\n expect(component.users()).withContext('User list after fetch')\n .toEqual(mockedUsers);\n expect(component.dataSource.data.length)\n .withContext('Data Source length after fetch').toBe(3);\n expect(component.dataSource.data).toEqual(mockedUsers);\n });\n\n it('should add a new user', async () => {\n const newUser = {\n id: 'id_4',\n username: 'user_name_4',\n email: 'test4@email.com'\n }\n\n await fixture.whenStable();\n await component.addUser();\n TestBed.flushEffects();\n\n expect(component.dataSource.data.length)\n .withContext('Data Source length after new user addition').toBe(4);\n expect(component.dataSource.data).toEqual([...mockedUsers, newUser]);\n });\n\n it('should remove user', async () => {\n await fixture.whenStable();\n await component.removeUser('id_2');\n TestBed.flushEffects();\n\n expect(component.dataSource.data.length)\n .withContext('Data Source length after user remove').toBe(2);\n expect(component.dataSource.data[1].id).toBe('id_3');\n });\n});\nI hope you found our stroll through UsersComponent testing as insightful as it was enjoyable. Testing,\nespecially with Angular's latest reactive features, doesn't have to be a pain in the neck. Actually, it's\nquite the opposite—it's a smooth, straightforward, and enjoyable task.
We've seen how tools like signal.set(), signal.update(), and effect() can be game-changers, making our\ntests not just necessary but a piece of cake. With the right approach and understanding, testing becomes\nless of a chore and more of an exciting part of the development process.
Incorporating these new features into our testing routine has shown us that it's not just about ensuring our\ncomponents are up to snuff. It's about embracing a more dynamic and enjoyable workflow. The tests we've walked\nthrough exemplify this mindset, proving that with Angular's advanced capabilities, we're fully equipped to\nhandle any reactive challenges that come our way, all with a smile.
\nSo, let's shake off any old notions that testing is a drag. With Angular's reactive features, we're ushering\nin a new era of testing that's efficient, effective, and, dare I say, fun :)
\n
\n
You can find access to the working application and tests on\nGitHub.
", "url": "https://devintent.com/blog/2024-08-20-testing-reactive-angular-components.md", "title": "Testing Reactive Angular Components - A Closer Look", "summary": "Explore the reactive testing of Angular components, focusing on the utilization of TestBed methods and Angular`s reactive signals and effects to create robust unit tests.", "date_modified": "2024-08-20T12:30:00.000Z", "tags": [ "angular", "testing" ] }, { "id": "blog/2024-08-19-the-progressive-journey-of-change-detection-in-angular.md", "content_html": "In this article, we'll delve into the evolution of Angular's change detection strategies, exploring how\nthey've transformed our applications to be more responsive and effective. Angular has made significant strides\nfrom the global\ntop-down Default\napproach to the widely\nembraced OnPush\nstrategy. However, the introduction of Signals-based methodology, as outlined in\nthe Angular documentation promises even more significant efficiency gains\nin the change detection.
\nWe'll explore the general inner workings of these strategies and analyze the performance gaps between them.\nFurthermore, we'll speculate on the direction of Angular's change detection mechanisms.\nSo, let's get started!
\nChange detection kicks off with any asynchronous browser events, and Angular relies on\nthe NgZone module to\nobserve these interactions. When an async event occurs, Angular triggers the change detection process,\ntraversing the view\ntree from top to bottom. However, there's a contrast in how components are marked for update across various\nstrategies
\nBack in the early days, Angular's default change detection was like a noisy neighbor. It kept an eye on every\ncomponent, binding, and dependency whenever any event happened, leading to updates throughout the entire\napplication. This method works, but it often leads to performance issues in bigger apps because it tends to\nperform checks even when everything has stayed the same.
\nWith the default change detection strategy, Angular keeps an eye on all components unless the view is\nexplicitly detached:
\n@Component({\n selector: 'detached',\n template: `Detached Component`\n})\nexport class DetachedComponent {\n constructor(private cdr: ChangeDetectorRef) {\n cdr.detach();\n }\n}\nThis strategy relies on the CheckAlways flag:
let shouldRefreshView: boolean = !!(\n mode === ChangeDetectionMode.Global && flags & LViewFlags.CheckAlways\n);\nwhich ensures that Angular performs change detection on every view and executes\nthe template function\nregardless of whether there are changes or not.
\n[![\"Default](\"/blog/change-detection-1/2-default-change-detection.png\")
Click on component \"H,\" which creates a domino effect throughout the entire app, even when it's just a false\nalarm.
\nTo speed things up, Angular brought in the OnPush change detection strategy. The OnPush option has been around\njust as long as the Default one. But to switch it on, developers needed to give their components a heads-up,\nletting them know they wanted to use it. OnPush is like a more discerning detective, only springing into\naction when a component's inputs change or events occur within that component. This optimized approach relied\non immutable states and reduced unnecessary checks, making our apps more straightforward and faster.\nSo, how does it work?
\nWith the OnPush strategy, change detection takes a back seat unless a component is flagged as dirty:
\nshouldRefreshView ||= !!(\n flags & LViewFlags.Dirty &&\n mode === ChangeDetectionMode.Global &&\n !isInCheckNoChangesPass\n);\nTo mark that a component as dirty, we can change an input property, emit an event, or manually\ninvoke the\nmarkForCheck()\nmethod, which marks the current view and all its folks up the family tree, all the way to the root view, for a\nthorough check.
\n@Component({\n selector: 'dirty',\n template: `Dirty Component`,\n changeDetection: ChangeDetectionStrategy.OnPush,\n})\nexport class DirtyComponent {\n constructor(private cdr: ChangeDetectorRef) {\n cdr.markForCheck();\n }\n}\nAngular then takes a tour of each dirty flagged view, executing the template function associated with its\nrespective component.
\n![\"OnPush](\"/blog/change-detection-1/3-onpush-change-detection.png\")
With OnPush, a click in the component \"H\" triggers an event through clicked component itself and its parents.
\nFrom Angular v16 onwards, Angular has been moving\ntowards adopting Signals, altering front-end state\nmanagement. Unfortunately, as of version 17\n, Signal-based Components remain under development,\ndelaying the full implementation of Signal-based change detection. In the meantime, Angular allowed us to\nutilize the power of Signals and OnPush strategy to mark individual components as dirty. This Local Change\nDetection ensures no more unnecessary checks for parent or child components designated as OnPush.
\nAdditionally, Angular's recent advancements in event detection include\nimplementing signal inputs, where input value updates occur\nbefore the change detection cycle. This improvement ensures that change detection does not execute if the\ntemplate doesn't use the input. Moreover, changing the value bound to an input no longer triggers a refresh of\nthe parent view, as with the OnPush strategy.
\nWhen we change the signal within a component's template using methods\nlike set()\nor update()\n, we kick off a chain reaction. This signal\ntriggers a notification\nto the reactive live consumer within the view, marking it as dirty through the\nmarkAncestorsForTraversal().\nBut it doesn't stop there – it also marks all ancestors, up to the root, with the HasChildViewsToRefresh\nflag. If the view is marked as dirty, the template function is called, and the current value is returned.
shouldRefreshView ||= !!(\n consumer?.dirty && consumerPollProducersForChange(consumer)\n);\nHowever, if the view is marked with the HasChildViewsToRefresh flag, there's no need to bother with the\ntemplate function. It just takes a shortcut, skipping the template function and diving right into checking the\nchildren. This clever move helps Angular avoid unnecessary tasks, operations, calculations, and comparisons,\nensuring everything runs smoothly and efficiently.
if (shouldRefreshView) {\n refreshView(tView, lView, tView.template, lView[CONTEXT]);\n} else if (flags & LViewFlags.HasChildViewsToRefresh) {\n detectChangesInEmbeddedViews(lView, ChangeDetectionMode.Targeted);\n const components = tView.components;\n if (components !== null) {\n detectChangesInChildComponents(lView, components,\n ChangeDetectionMode.Targeted);\n }\n}\nLooking ahead, Angular seems set to embrace a Signals-based Change Detection system fully. It's like getting a\nsuperpower to track changes with laser precision, eliminating the need for NgZone to manage execution context\ncompletely. By going zone-less, developers will have better, fine-grained control over change detection,\nenabling a more efficient and focused approach and optimizing performance even further by running Change\nDetection only when necessary. This approach will fundamentally change how Angular tracks and handles changes,\nallowing developers to pinpoint precisely where and when updates should occur.
\nHowever, transitioning to this new paradigm requires developers to understand signals better to harness their\nfull potential. Despite the learning curve, the performance and scalability gains make it a worthwhile\ninvestment for projects aiming for optimal performance.
\nAs Angular continues to evolve, developers must stay updated with these advancements in Change detection\nstrategies.
\nThe journey from the default strategy through OnPush and towards Signals-based Change Detection highlights\nAngular's commitment to enhancing performance and scalability. By adopting these advanced strategies,\ndevelopers are empowered to build functional and exceptionally performant Angular applications.
\n![\"Signal-based](\"/blog/change-detection-1/4-signals-change-detection.png\")
In the world of Local Change Detection, a change in component \"F\" gets the attention it deserves without\nredundantly checking parent or component children.
\nIn conclusion, the evolution of change detection in Angular reflects a constant effort to refine and optimize\nperformance. Embracing these advancements empowers developers to create Angular applications that are not just\nfunctional but also highly performant, ensuring a seamless user experience across a wide range of\napplications. Given the progress that has been made in this regard, I look forward with optimism to further\nreleases of the Angular framework.
\n
\n
The principle of change detection can be viewed in\nthis GitHub application.
", "url": "https://devintent.com/blog/2024-08-19-the-progressive-journey-of-change-detection-in-angular.md", "title": "The Progressive Journey of Change Detection in Angular", "summary": "Angular change detection strategies evolution, detailing the transition from the default approach, OnPush and the upcoming Signals-based method, highlighting their impact on performance and application efficiency.", "date_modified": "2024-08-19T17:15:00.000Z", "tags": [ "angular" ] }, { "id": "blog/2023-09-26-build-time-benchmarking-using-angular-cli.md", "content_html": "In this article, we’ll take a look at the impact of different build options of\nthe Angular CLI on the build time of a monolithic application. Building is\nusually on a critical path of the continuous integration (CI) pipeline—that is,\nany changes to build duration impact the total CI time. The Angular team makes\na few build optimizations available for developers, and in this post, we’ll\ntake a look at their impact.
\nTo make the data reproducible and relevant, I’ll run the test builds with\nCircleCI. Using external servers for the build isolates the measurement from my\nlocal environment. At the same time, the results come from machines that others\nare using for building as well.
\nThe key measurement I’ll pay attention to is the time needed to run the npm\nrun build command:
![\"Screen](\"/blog/ng-build-monolithic/1-build-time.jpg\")
At this level, I expect to see the most direct results of the optimization we\nuse. If we manage to cut the build time in half, then we should see this impact\nhere.
\nAnother value to consider is the time of a whole build job. This will be\nespecially important for optimizations that come with positives and negatives:\nfor example, caching can speed up some operations, but part of the gain will be\neaten by the downloading and uploading cache.
\n![\"Screen](\"/blog/ng-build-monolithic/2-job-time.jpg\")
The last measurement for us to consider is the overhead: the difference between\nbuild script and build job. It will contain everything that is done before or\nafter the build: restoring the cache, installing dependencies, saving the\ncache. With this number, we should see clearly the downsides of some\noptimization.
\nI’ll repeat each test build 5 times under the same circumstances and use the\naverage of the measurements as the measurement value. In this way, I’ll be able\nto reduce a bit of random noise in the data without turning it into a full\nscientific experiment.
\nAs a benchmark, I’m using the build time of a simple application generated and\nbuilt with the Angular CLI. The application models the real world complexity by\nincluding 1000 components. This approach is inspired by Nrwl’s Angular\nbenchmark. Each component\nis very simple:
\nsrc/app/component1/component1.component.ts:
import { Component } from '@angular/core';\n\n@Component({\n selector: 'app-component1',\n templateUrl: './component1.component.html',\n styleUrls: ['./component1.component.css']\n})\nexport class Component1Component {\n\n}\nsrc/app/component1/component1.component.html:
<p>component1 works!</p>\nAnd the whole application just displays each component one after another:
\n![\"Application](\"/blog/ng-build-monolithic/3-app-interface.png\")
The biggest blind spot is the lack of third-party libraries. This is something\nthat almost all real-world applications do, but including it in the benchmark\nwould tie the results to the set of libraries used in the example application.
\nIn my test, I’m measuring the build time in the following setups.
\nThis is the standard build as it’s generated by Angular CLI. Important features are as follows:
\nng cache for CI—so each build during CI starts from scratchnpm installesbuild is a promising bundler with much better performance than Webpack:\naccording to its own website, it’s up to 100 times faster. Because of its\nspeed, since version 14, the Angular team has provided an experimental builder\nbased on esbuild. It was recently improved in version 15. It can be turned on\neasily, with just 1 line change in angular.json:
\"architect\": {\n \"build\": {\n- \"builder\": \"@angular-devkit/build-angular:browser\",\n+ \"builder\": \"@angular-devkit/build-angular:browser-esbuild\",\n \"options\": {\nNote! So far, this change affects only the build—the development server is\nstill using Webpack. This is likely to change in version 16.
\nFor local builds, Angular CLI caches build results to save time on reruns. By\ndefault, this feature is turned off for CI. To use caching during CI, we need\ntwo changes:
\nYou can turn on caching with two commands:
\nng config cli.cache.environment all\nng cache enable\nManaging cache files for CI will require changes in configuration. You can find my change for CircleCI here.
\nTypeScript 5 promises up to 10% improvement for the build time. It’s not yet\navailable for Angular applications, but it’s on track to come in version 16.\nFor my tests, I’m updating Angular to pre-release version 16.0.0-next.4.
The builds I’ve run measured as follows:
\n| | npm run build (s) | Build job (s) | Overhead (s) |\n|------------------|-------------------|---------------|---------------|\n| baseline | 57.8 | 92 | 34.2 |\n| esbuild | 14.4 | 50.2 | 35.8 |\n| hot build cache | 31.4 | 67 | 35.6 |\n| cold build cache | 66.8 | 104.2 | 35.6 |\n| TypeScript 5 | 55 | 84.8 | 29.8 |
\nThe baseline time needed to complete npm run build was on average 57.8s. The\nbiggest improvement we can see is with switching to esbuild: it becomes 4\ntimes faster and takes only 14.4s to build. Both builds have very similar\noverhead. With esbuild, the build job takes 56% of time that was needed in the\nbaseline case—an excellent improvement.
Another optimization—caching of the Webpack build—looks very promising as well.\nBecause there are more files cached, I expected a clear increase in the\noverhead. It went from 34.2s to 35.6s, but this difference could be\nstatistically insignificant. Caching of the build has two effects:
\nLastly, an interesting case is updating to TypeScript 5. The time needed to\ncomplete the npm run build lowered slightly from 57.8s to 55.5s. At the same\ntime, the overall build job took 84.5s instead of 92s, which is a better\nimprovement than the build script alone. This could be explained by the more\nefficient installation—maybe TypeScript 5 or other v16 dependencies are faster\nto install.
\nYou can find our test application here.
\nOur team at DevIntent is highly experienced in web development, including\nframework migration and updates. Check out our offerings\nor reach out.
", "url": "https://devintent.com/blog/2023-09-26-build-time-benchmarking-using-angular-cli.md", "title": "Build time benchmarking using Angular CLI", "summary": "Build time benchmarks of various configurations in the Angular CLI.", "date_modified": "2023-09-26T12:30:00.000Z", "tags": [ "angular" ] }, { "id": "blog/2023-05-01-angular-v-16-features-and-improvements-we-re-excited-about.md", "content_html": "With Angular version 15 released on November 16 and the next version expected\nbefore summer, let’s see what upcoming changes look the most exciting.
\nA lot of optimization in Angular happens at build time. For this to be\npossible, Angular provides a custom compiler. The compiler takes care of things\nspecific to Angular: ahead-of-time compilation or catching issues in the\ntemplates. The build is complex, but Angular CLI provides you all the\nconfiguration you need. Under the hood, Angular CLI uses Webpack, a well\nestablished bundler with a very active community.
\nWhile Webpack is the most popular bundler available, it has its\ndownsides—especially speed when it builds larger codebases. Whereas Webpack is\nin active development and there are incremental improvements in speed between\nversions, there are other bundlers that take a fundamentally different approach\nand boast greatly improved speeds. A slower bundler causes slower builds, and\nthis can negatively affect productivity in the project at all stages—from\ndevelopment to continuous integration.
\nTo allow the Angular community to enjoy the benefits of faster bundlers,\nthe Angular CLI has offered an experimental esbuild configuration since\nversion 14,\nand it’s been\nreported to\nlower build time by up to 44%. The\nRoadmap also\nlists further investigation and progress toward making the improved builds\nstable, so we hope to see continued speed increases coming to applications\nbuilt with the Angular CLI.
\nDue to their size, images have a disproportionately large impact on web\nperformance. Managing them well is especially important for the mobile user\nexperience for a couple of reasons:
\nManaging images well can be difficult, especially in applications rendered on\nthe client side. Improvements to image management for both users and developers\nare welcome. So it’s promising to\nsee on the roadmap\nfurther enhancements to NgOptimizedImage\nthat the Angular team plans to add to the framework.
\nIn my AngularJS development work, I often use this snippet to access my\nservices from the dev tools console:
\n angular.element(document.body).injector().get('serviceName')\nI find it very helpful to be able to test my methods interactively in the\nbrowser as I develop them. For that reason, I’m looking forward to seeing the\nupdates in Angular DevTools that will bring\ndependency injection debugging APIs.
\nThose are the changes I’m the most excited about in that are on the way to\nbecoming part of Angular v16. You can find the list of priorities for the\ncurrent development in the project’s roadmap.
\nOur team at DevIntent is highly experienced in Angular development, testing,\nand software quality. If you'd like to chat about how we can help you, please\ncontact us at sales@devintent.com.
", "url": "https://devintent.com/blog/2023-05-01-angular-v-16-features-and-improvements-we-re-excited-about.md", "title": "Angular v16 Features And Improvements We’re Excited About", "summary": "Some of our favorite improvements coming in the new release.", "date_modified": "2023-05-01T12:30:00.000Z", "tags": [ "angular" ] }, { "id": "blog/2023-04-28-how-to-speed-up-your-web-application-with-brotli-compression.md", "content_html": "Lossless compression is a great way of lowering the amount of data that users\nhave to download to access your application. Minimizing data transfer improves\nseveral critical metrics of your application:
\nCurrently, Brotli is the most efficient compression algorithm for website code.\nAccording to benchmarks,\nHTML, CSS, and JS files are more than 10% smaller when compressed with Brotli\ncompared to traditional GZIP. Brotli offers better results and is supported\nacross all modern browsers—in most cases, it should be the go-to solution for\ncompressing website data.
\nIsn’t compression something done automatically by your hosting provider? It can\nbe, but there are few downsides to depending on a third party to compress the\napplication:
\nAs an alternative to automatic compression provided by hosting, you can\ngenerate .br files every time you build your app for deployment. In this way,\nyou can ensure that .br files are up to date and ready on the server when\nneeded—and that the user experience will not be affected by slow compression.\nDepending on your hosting setup, there will be different ways to configure your\nserver to use .br files for user agents that accept Brotli.
If you are interested in using Brotli for your AngularJS or Angular application, our team recently\npublished a guide on the XLTS.dev blog\nhere.
\nOur team at DevIntent is highly experienced in Angular development, testing,\nand software quality. If you'd like to chat about how we can help you, please\ncontact us at sales@devintent.com.
", "url": "https://devintent.com/blog/2023-04-28-how-to-speed-up-your-web-application-with-brotli-compression.md", "title": "How To Speed Up Your Web Application With Brotli Compression", "summary": "Overview of Brotli—compression optimized for web documents.", "date_modified": "2023-04-28T21:00:00.000Z", "tags": [ "perf", "ux" ] }, { "id": "blog/2023-01-23-release-of-angular-15.md", "content_html": "On November 16, 2022, the Angular team published version 15 of the framework.\nLet’s look at what changes are available in the newest version.
\nStand-alone components are components that are defined outside any NgModule.\nThey are providing a simplified API that reduces the boilerplate necessary to\ndefine a component. Stand-alone components, directives and pipes integrate\nnicely with the existing Angular landscape. They
\nYou can learn more in the official guide.
\nAlong with the stand-alone components, some services are available in a lighter\nform that works better with tree shaking. These APIs will help you keep your\nreusable code smaller—instead of including entire modules with all the features\nyou don’t use. Thus, you can pick only the things that you need. All the rest\nis dropped during the build process with tree shaking.
\nprovideRouter allows you to\npick various features of the\nrouter to optimize your build size:
type RouterFeatures = PreloadingFeature | DebugTracingFeature | InitialNavigationFeature | InMemoryScrollingFeature | RouterConfigurationFeature;\nHttpClientSimilarly,\nprovideHttpClient\nallows you to choose from the following\nfeatures:
enum HttpFeatureKind {\n Interceptors\n LegacyInterceptors\n CustomXsrfConfiguration\n NoXsrfProtection\n JsonpSupport\n RequestsMadeViaParent\n}\nThe NgOptimizedImage directive\nhas become stable. The directive enforces best practices in loading images,\nimproving the page's load performance.
\nTogether with an ImageLoader, it\ncan be used to generate the appropriate resource URL for a given image file.\nYou can learn more about this (including plans for the future) on the Chrome blog in\nOptimizing Images with the Angular Image Directive.
\nAs of version 15, Angular allows you to reuse existing directives as building\nblocks when creating new directives or components. With\nhostDirectives, you\ncan add directives to your host element, effectively combining a few directives\ninto one. It is similar to how some languages support multiple inheritance in\nclasses. You can learn more, including performance implications, in the\nofficial guide.
The Angular team migrated the Angular Material components to reuse\nframework-independent code available in Material Design Components for the\nWeb (\"MDC\"). This\nresults in an improvement in how close the components are following the\nMaterial Design 2 specification; in the future, it will allow for switching styling\nto Material Design 3.
\nIf you overwrite many styles in Angular Material components, be prepared for\na large amount of refactoring. Migration requires changing the internal DOM structure and\nstyling of the components, as well as some changes to the external API. You can\nlearn more about what was changed and what updates are needed in the application in\nthe MDC migration guide.\nThe previous components are deprecated, but are still available to smoothen the\nmigration.
\nBesides new additions to the framework, a few things were deprecated and will\nbe removed in a future version. If you are using any of the features below in\nyour apps, you should start making plans to move away from them.
\n@angular/flex-layoutThe Angular team will stop releasing new versions of @angular/flex-layout — but\nthey will publish security and browser compatibility updates for the following\nyear. Instead, there are two alternatives available in pure CSS:
You can find the official recommendations in the article on the Angular blog in\nModern CSS in Angular: Layouts.
\nprovidedIn: any and providedIn: NgModuleBoth options were decided to be uncommon and confusing enough to be deprecated.\nIf you use them, check the official release\nannouncement\nto see the way forward. We will no longer be able to register services in lazy\nloaded modules using providedIn: NgModule, but only by using an old fashion\ntechnique—using the NgModule.providers array.
As always, you can find relevant update instructions in the Angular Update\nGuide.
\nStarting with version 15.1.0, Angular supports self-closing tags for non-native\nHTML elements (including Angular components). This will allow decluttering your\ntemplates by omitting closing tags. For example, you can replace\n<my-component></my-component> with just <my-component />.
Our team at DevIntent is highly experienced in web development, including\nframework migration and updates. Check out our offerings or\nreach out.
", "url": "https://devintent.com/blog/2023-01-23-release-of-angular-15.md", "title": "Highlighting the Release of Angular v15", "summary": "What's new in the latest Angular release.", "date_modified": "2023-01-23T21:00:00.000Z", "tags": [ "angular" ] }, { "id": "blog/2023-01-20-better-way-to-share-components-in-angular.md", "content_html": "In order for large web applications to be scalable, they are usually broken up into a number of modules.\nVery often, we need to reuse individual Components,\nPipes, and Directives in many\nplaces of our application. Duplicating code for repetitious items is not the best practice. This is why we\nusually create a shared module, registering all reusable and generic elements of our application there, so\nthat we can use them later in any feature module.
\nIt makes sense to create a global place for all reusable items. Unfortunately, it also has disadvantages.
\nAs the project evolves and the demand for more and more reusable elements increases, the shared module can grow significantly. We\nmust be aware. that in order to use one component, we have to import all the elements registered in the shared\nmodule, which becomes inefficient.
\n![\"Shared](\"/blog/scam-1/shared.jpg\")
Let's look at the situation from a sample application.
\n![\"Angular](\"/blog/scam-1/folder-structure.png\")
We have defined 2 modules, AppModule and UsersModule. They both use ButtonComponent.\nAdditionally, UsersModule uses a FilteredListComponent with users, which is also a reusable component - it\naccepts any shape of a single list element. We put both reusable components in a shared module.
export module SharedModule {\n export const name: string = 'Shared';\n\n angular\n .module(SharedModule.name, […])\n .component(FilteredListComponent.componentName, FilteredListComponent.componentConfig)\n .component(ButtonComponent.componentName, ButtonComponent.componentConfig);\n}\nangular.module('AppModule', [SharedModule.name])\nangular.module(UsersModule.name, [SharedModule.name]);\nAs we can see, AppModule needs to import the entire SharedModule to access the reusable ButtonComponent.
Now imagine that our application defines hundreds of such reusable elements. We won't need all of\nthese elements in every module. A Single Component Angular Module (\"SCAM\") comes to the rescue.
\nSingle Component Angular Module, or SCAM for short, is the concept of creating small, encapsulated and\nreusable AngularJS / Angular modules with only one Component (or Directive, or Filter / Pipe).
Instead of a global module with elements shared between the entire application, we can define modules for each\nof the elements:
\nexport module ButtonModule {\n export const name: string = 'ButtonModule';\n angular\n .module(ButtonModule.name, ['ngMaterial'])\n .component(ButtonComponent.componentName, ButtonComponent.componentConfig);\n}\nexport module FilteredListModule {\n export const name: string = 'FilteredListModule';\n angular\n .module(FilteredListModule.name, ['ngMaterial'])\n .component(FilteredListComponent.componentName, FilteredListComponent.componentConfig);\n}\nWe can see that we can easily build a module architecture that provides only the required elements for given\nviews, without the need to import unused Components, Filters / Pipes, or Directives.
export module UsersModule {\n angular.module(UsersModule.name, [ButtonModule.name, FilteredListModule.name]);\n}\nmodule AppModule {\n angular.module('AppModule', [ButtonModule.name]);\n}\nNote that the SCAM-based architecture allows you to refactor the code quickly. If you reach the point where\nUsersModule no longer requires the use of buttons, you would need to delete the dependency to remove it.\nAdopting this method gives you a considerable advantage over shared modules when migrating from AngularJS\nto Angular. You can now migrate application sections more efficiently by breaking them into independent\nbut valuable parts because you depend on only one component and not on sets of components.
Another point I would like to make is the similarity with Standalone Components. Let's recall that since\nAngular version 14, we can write code without using Angular modules. Having SCAM defined:
\nimport {UpperCasePipe} from '@angular/common';\n\n@Component({\n selector: 'app-button',\n template: `\n <button mat-button>Sample Button</button>\n `,\n})\nexport class ButtonComponent {\n // your component's code\n}\n\n@NgModule({\n declarations: [ButtonComponent],\n})\nexport class ButtonComponentModule {\n}\nwe can easily migrate to Standalone Components without worrying that we messed up something in other parts\nof the application, since it is an independent piece of code.
\n@Component({\n standalone: true,\n selector: 'app-button',\n template: `\n <button mat-button>Sample Button</button>\n `,\n})\nexport class ButtonComponent {\n // your component's code\n}\nUsing common SCAMs creates some overhead because you have more modules and more imports in your feature\nmodules. On the other hand, you get smaller, better encapsulated modules that are less\ncumbersome to maintain. SCAM-based code refactoring is much more straightforward and less time-consuming.\nEven more complicated migrations from AngularJS to Angular will be simpler to implement, and applying\nStandalone Components in the project will reduce the risk of bugs.
\nAs I mentioned SCAM is a concept, not imposed by a specific framework or API version. So it can be used\nwherever we are dealing with shared components.
\nThe source code for this example is in this GitHub repository.
\nOur team at DevIntent is highly experienced in web development, including framework migration and updates.\nCheck out our offerings or reach out.
", "url": "https://devintent.com/blog/2023-01-20-better-way-to-share-components-in-angular.md", "title": "A Better Way to Share Components", "summary": "A way to replace shared modules with a Single Component Angular / AngularJS Module.", "date_modified": "2023-01-20T21:00:00.000Z", "tags": [ "angularjs", "angular" ] }, { "id": "blog/2023-01-11-ensuring-an-easier-migration-path-with-framework-agnostic-libraries-using-axios.md", "content_html": "How often do you use data in your applications? I do this in every application I implement.
\nWe typically fetch data using an HTTP client in a service. Sometimes, the HTTP client is even used\ndirectly in a component, which is not very good practice. But this article is not about good and bad practices,\nso let’s move on.
\nSo inside the Service, we can inject another Service, for\nexample, $http (AngularJS),\nor HttpClient (Angular). The built-in HTTP Angular services\nare outstanding.
When AngularJS was written, the browsers didn't have a\nfetch() API. Well, now times have changed, and\nthey do!
\nSo why don’t we use fetch() instead of the HTTP client? You might think:
\n\nWell, it’s just easier to use the build-in HTTP client
\n
or simply:
\n\n\nWhy should I use something else if I get an HTTP client with the framework I’m using?
\n
Think about React, Vue.js, other web frameworks or just plain\nJavaScript. What are they using? Well, they use the fetch() API. And if they need something more\ncomplex and involved, they can use things like Axios - a promise-based HTTP client\nfor Node.js and the browser.
![\"Axios](\"/blog/axios-1/axios-logo.png\"){kind=logo}
Let’s look at an AngularJS and Angular-based application that does not use the built-in HTTP client.\nHere’s what it might look like in AngularJS:
\nimport axios, {AxiosResponse} from 'axios';\nimport {User} from '../users.module';\n\nexport class UsersService {\n loadAllUsers(): Promise<AxiosResponse<User[]>> {\n return axios.get('assets/mocks/users.json');\n }\n}\nand Angular:
\nimport {Injectable} from '@angular/core';\nimport axios, {AxiosResponse} from 'axios';\nimport {User} from '../users.module';\n\n@Injectable({\n providedIn: 'root'\n})\nexport class UsersService {\n loadAllUsers(): Promise<AxiosResponse<User[]>> {\n return axios.get('assets/mocks/users.json');\n }\n}\nSo, as we can see, we define a service called UsersService in both cases. And you’ll notice we're pulling in\nAxios. We can also see a method named loadAllUsers(). That method invokes Axios APIs, which return\na Promise which\nwill eventually resolve with the returned data.
The code examples above are straightforward and very similar. But notice what you do not see as well. It’s\nnot just the HTTP service switched out for Axios in this case.
\nWhere are the Observables in the Angular-based code example?
\nNow RxJS is extremely powerful and valuable. But do you ever feel\nweighed down when you’re getting into a new technology? Maybe you feel like:
\n\n\nI don’t need this yet
\nI shouldn't need to learn all of these concepts to understand a basic example.
\n
Well, with this, you don’t have to. With fetch() and Axios, you can jump right into using Promises. But\nthere is an even more significant advantage that we may overlook at first glance.
As some of you know, migrating an AngularJS-based application to Angular is a real challenge. Interfaces and\nAPIs are so different that it's safe to say that they are two completely different frameworks. The way the\nHTTP client is used in the two mentioned versions is also completely different.
\nHere is an example of how we use the built-in $http service in AngularJS:
import {IHttpResponse, IHttpService} from 'angular';\nimport {User} from '../users.module';\n\nexport class UsersService {\n constructor(private $http: IHttpService) {\n }\n\n loadAllUsers(): Promise<IHttpResponse<User[]>> {\n return this.$http.get('assets/mocks/users.json');\n }\n}\nAnd here is an example of using the built-in HttpClient service for Angular:
@NgModule({\n imports: [HttpClientModule],\n ...\n})\nexport class UsersModule {\n}\nimport {HttpClient} from '@angular/common/http';\nimport {Injectable} from '@angular/core';\nimport {Observable} from 'rxjs';\nimport {User} from '../users.module';\n\n@Injectable({\n providedIn: 'root'\n})\nexport class UsersService {\n\n constructor(private http: HttpClient) {\n }\n\n loadAllUsers(): Observable<User[]> {\n return this.http.get<User[]>('assets/mocks/users.json');\n }\n}\nMaybe we should consider using a library that is independent of the framework used and guarantees a consistent\nAPI, whether in AngularJS, Angular or even React. Is Axios worth using? We would\nsave ourselves the problem and time of rewriting all Services to an entirely new API.
\nThere are some reasons why AngularJS/Angular have their HTTP clients.
\nIn both frameworks, the respective HTTP clients tie into the change detection system, automatically triggering\na change detection as soon as a response is received.
\nIf we use fetch() or Axios, we might need to handle that ourselves. This is not necessarily\nprohibitively complicated, but it’s worth remembering.
Another difference in AngularJS that could break your application if not addressed is that the built-in HTTP\nclient returns $q promises, the AngularJS’s built-in promise\ntype rather than regular Promise instances. So it is worth paying attention to what type is returned from\nthe services and considering this argument when making a decision about the HTTP client.
Another difference worth mentioning when using fetch() is that it does not support some features\noffered by built-in clients, such as request/response interception, transformations, etc.
One last difference between fetch() and Axios is that they might be a little less easy to handle in tests\ncompared to the built-in HTTP clients, which offer utilities that make testing easier.
With the above in mind, we should decide on the HTTP client based on our goals and objectives.
\nI am not trying to convince anyone that Axios is better than HttpClient. But I hope I have\nsucceeded in getting you to reflect on the future of your application. Perhaps years from now, Angular will be\nanother completely different framework implementing a new API. Regardless, using a framework-agnostic\nlibrary like Axios will ensure that your code that fetches data will look and function similarly!
Sample application code based on AngularJS and Axios is available in\nthis GitHub repository.
\nOur team at DevIntent is highly experienced in web development, including framework migration and updates.\nCheck out our offerings or reach out.
\nWeb application platform migrations are large and often daunting undertakings.\nEspecially when new feature developments, budgets, and revenue-driving business priorities have you pulled in\nmany, and sometimes conflicting, directions.
\nWhen evaluating a migration strategy, one of the first questions is whether to use internal resources or\npartner with a migration expert. Initially, in-house migrations often feel like the easier choice, and the\nsticker shock can scare some away from bringing in outside help.
\nHowever, internal teams can become overwhelmed with competing priorities or need more technical expertise,\ncausing the migration to drag on for years or, worse yet, never reach successful completion. With a closer\nlook, you’ll find the upfront costs of a partner return significant savings from many angles over the life of\nthe project.
\nLet’s see how partnering with a migration expert helps save time and money while achieving a successful\nmigration.
\nMigrations to newer web application platforms are an experienced migration architect’s specialty. Their\nmigration-specific expertise provides a blueprint for your application to work right, not only when the\nmigration is complete but also along the way. By deploying a hybrid environment, they can ensure the\napplication will be in a workable and releasable state throughout the migration. Compared to attempting a\nmigration in-house, this is a significant advantage that allows your team to focus on the core business goals\nof developing new features and applications that grow your top and bottom line.
\nWhen you already have developer talent in-house, why should you trust outside help? Because a migration\narchitect’s skillset is unique to migrations, drastically differing from a developer’s proficiency in writing\napplication code. The mammoth undertaking of ramping up your team’s knowledge for a successful platform\nmigration is a legacy tech investment that won’t result in an ROI. You’ve burnt months or years of valuable\ntime preparing for an undertaking having high odds of failure. Instead, by using an expert partner, you can\nhave confidence in your approach while significantly increasing your success rate and starting your migration\nimmediately.
\nA migration expert can complete the project with fewer costs and a shorter delivery time when compared to\nusing in-house resources. Additionally, you’ll have confidence the correct route was taken, not requiring\ncostly revisits to address something twice. You can get where you need to go faster and at a lower cost than\nin-house. Depending on your budget allocations, you can dynamically throttle up your project’s momentum with\nfully dedicated migration services or with consistently dedicated part-time work.
\nStops the accumulation of technical debt by ceasing the creation of antiquated end-of-life code. Each\nincrementally migrated module is proven to work when complete, not just verified at the end of the migration.\nFurther application development, like fixes and new features, can continue alongside the migration. Your team\ncan quickly develop on a modern platform, improving your application performance and security while reducing\nimplementation times for new features.
\nNo need to hire, train, or maintain migration-specific talent for the project, allowing you to avoid overhead\ncosts and the time spent recruiting. Choosing to upskill internal talent for a migration comes with\nconsiderable risk. Many developers are unwilling to learn competencies on a deprecated platform or lack the\nspare time required. There are also chances of a fatal architecture error or newly trained developers\ntransitioning away from the project part-way through. These obstacles could leave you upside down with a\nbroken application or scrambling to hire replacements with a skill set that’s becoming obsolete.
\nYou mitigate substantial risk by involving a proven web application migration expert early in the planning\nstages. Common errors avoided include confusing the easiest migration path as optimal for your future needs,\nchoosing the incorrect migration tools, or not knowing when an app is better suited for a complete rewrite.\nUltimately all these things could have severe negative consequences and huge costs associated.
\nThe points above demonstrate a compelling business case of how teaming with a migration expert saves money and\ntime. Whether you’re in the planning stages of a migration, stuck in a perpetual rut of deciding which\nplatform to move to, or stalled halfway through, help is available. Keep your momentum moving forward and\nproject on target without breaking the bank.
\nTo learn more about the best path for your business, schedule\na quick introductory chat with our team.
", "url": "https://devintent.com/blog/2022-12-22-why-an-expert-migration-partner-ultimately-saves-you-money.md", "title": "Why an Expert Migration Partner Ultimately Saves You Money", "summary": "Learn how to ensure the success of your migration while saving money, shortening the project timeline, and avoiding critical errors.", "date_modified": "2023-01-26T22:00:00.000Z", "tags": [ "it-leadership" ] }, { "id": "blog/2022-12-01-how-to-support-users-light-dark-mode-preferences-in-your-web-application.md", "content_html": "Your website will be used in many contexts, and you should ensure that it can adapt to them. We have responsive websites for different screen sizes—a layout that changes to fit the screen width. Similarly, we can make sure our website looks good in the dark. In this article, I'll show you how to switch your web application automatically to dark mode—thereby ensuring that your users are always interacting with the version of your app that best suits their needs.
\nDark mode is a color scheme optimized for use in a low-light environment. Usually, it inverts the traditional color combination and uses light letters on a dark background. Light or dark mode is controlled by either the operating system or the browser. On macOS, you can select one of three options:
\nSome browsers—for example, Firefox—either use a theme based on the OS setting or allow the user to override it on the browser level.
\nHow do websites use switch to dark mode to respect users' preferences? With the media query option prefers-color-scheme, which is supported by 93% of browsers according to Can I use data.
\nMany websites already switch to dark mode automatically based on the users' preferences. For example:
\nGoogle:
\n![\"Screenshot](\"/blog/darkmode/1-google-screenshot.png\")
Twitter:
\n![\"Screenshot](\"/blog/darkmode/2-twitter-screenshot.jpg\")
As others have pointed out, supporting dark mode increases accessibility for your web application. Some visual impairments cause users to prefer viewing websites and applications in dark mode. Thus, by implementing it in your application, you make sure everyone in your user base can use your product effectively.
\nBesides accessibility concerns, for many users, dark mode is their preferred way of using applications. When the operating system is set to dark mode, most of the interface elements become dark. With many applications and websites following this setting, any application that sticks to the bright colors stands out negatively because it forces the bright colors onto the user.
\nIn order to support two color schemes on your website, every color on your website has to be set twice—for the light and the dark mode. To avoid code duplication, you can use native CSS variables—they have widespread support (source):
\n![\"Support](\"/blog/darkmode/3-css-variables.jpg\")
You can use it very easily in any web application. You define two files defining variables:
\nstyles.light.css:
:root {\n --main-bg-color: #fafafa;\n --main-color: #000000de;\n}\nstyles.dark.css:
:root {\n --main-bg-color: #303030;\n --main-color: #fff;\n}\nThen, in your main style file you use those variables for styling and import the color mode file based on user preferences.
\nstyles.css:
@import url(\"styles.light.css\") (prefers-color-scheme: light);\n@import url(\"styles.dark.css\") (prefers-color-scheme: dark);\n\nbody {\n background-color: var(--main-bg-color);\n color: var(--main-color);\n}\nHere you can find the example code, and the website in action
\nDepending on your use case, you may need some fallback values to ensure support for older browsers, styles.css with fallback:
body {\n background-color: #fafafa;\n background-color: var(--main-bg-color);\n color: #000000de;\n color: var(--main-color);\n}\nOur team at DevIntent is highly experienced in web development, including framework migration and updates.\nCheck out our offerings or reach out.
", "url": "https://devintent.com/blog/2022-12-01-how-to-support-users-light-dark-mode-preferences-in-your-web-application.md", "title": "How to Support Users’ Light/Dark Mode Preferences in Your Web Application?", "summary": "How to automatically switch styling between dark and light modes.", "date_modified": "2022-12-01T00:00:00.000Z", "tags": [ "UX", "accessibility" ] }, { "id": "blog/2022-10-15-back-and-better-than-ever-takeaways-from-ng-conf-2022.md", "content_html": "Earlier this month marked another successful year of ng-conf, Angular's most prominent conference. This year's\nconference was the first one back in-person since 2020 and hosted more than 50 speakers from around the world.\nWhile we wait for more presentations\nto be released online, our team wanted to share some of our key takeaways from the event, focusing\nspecifically on the areas of security, performance, and architecture.
\nLet's get started!
\n![\"Loading\"](\"/blog/ng-conf-2022/performance.jpg\")
From performance at scale, to tuning, to general best practices, web application performance was a big topic\nat ng-conf 2022. While we didn't have the opportunity to attend every presentation, we picked out a few\nhighlights we thought were particularly valuable.
\nLara Newsom's \"The Tell-Tale Code\" listed three standard Angular Code Smells:
\nIn a presentation focused on the anatomy of slow web applications, Misko Hevery shared that the amount of\nJavaScript code in applications has caused performance problems for even the most mature players in the\nspace. This increase, he said, is not necessarily due to bad practices but can be attributed to the evolution\nof JavaScript itself. Today, JavaScript is capable of so much more and, naturally, developers want to\ntake advantage of that increased functionality.
\nMisko shared that the most common problem is extraneous JavaScript code. By optimizing that code, we can correct\na lot of existing performance issues, even in larger web applications. He demonstrated one method by\ncomparing Replayable (Angular, Vue, React, Svelte), where JavaScript code is fetched\nfrom the server and executed on the browser side, and Resumable frameworks (Marko,\nWiz, Qwik), where code is\nexecuted on the server side, is serialized, and then encapsulated in HTML for user interaction.
Ady Ngom presented seven basic principles to develop faster Angular applications. He mentioned that the\nsize of the application does not matter much when discussing performance. Budget plays a key role. He shared\npractical strategies, like lazy loading images, optimizing event detection with\nngZone, the Ivy engine,\nnon-blocking processes, and prefetching all possible resources. These are captured in his \"Angular Checklist\"
\nMichael Hladky spoke to Runtime Performance, comparing the performance of a regular Angular application with\na Zone-Less Angular application. He explained how event detection works in the framework and presented an\nefficient way of event detection and template re-rendering using the RxAngular\nlibrary as an example.
\nBen Lesh, in turn, mentioned a patch release for RxJS version 7.5.4,\nwhere stream operations are performed 31 times faster than in previous versions! So it's worth checking\nthe library version you're working with.
\nOn the last day, Houssein Djirdeh talked about Chrome browser features and improvements in the area of web\napplication performance:
\nFinally, we got to experience a deep dive into image optimization best practices for Angular, presented by\nKara Erickson during her session called \"Image Optimization Best Practices with Angular\".
\n![\"Security\"](\"/blog/ng-conf-2022/security.jpg\")
Security is one of the greatest challenges in software development. It is a critical defense mechanism meant\nto cover any potentially vulnerable surfaces, as it's impossible to predict every form an attack may come in.\nHowever, despite its inherent importance, security is often overlooked or treated as an afterthought during\ndevelopment.
\nAfter all, we count on the framework to do the security work for us, and the rest of the\ndependencies… well, since they have been released for production, they should be safe, right? :) Of course\nnot!
\nIn their cleverly-named presentation, \"OAyDaBy AAmn=/y SAinRe9L TArT, wait what?\" Jessica Janiuk\nand Joey Perrot raised topics related to the security of the Angular framework. They covered topics on secure\nsoftware development, operations to deploy and run applications securely in production, and how to ensure\nthat applications are protected by default when using Angular.
\nAlisa Duncan's session, on the other hand, focused on the TOP 2 OWASP vulnerabilities from 2021:
\nBroken Access Control, which is the failure to properly enforce policies such that users cannot act\noutside their intended permissionsInjection - the attacker sends data to an application in a way that will change the meaning of commands\nbeing sent to an interpreter.She highlighted what can happen when an attacker has elevated access within the application and explained\nsome of the defenses we have against these attacks, both built into Angular and what we can do ourselves, as\ndevelopers.
\n![\"Diagram\"](\"/blog/ng-conf-2022/architecture.jpg\")
As you might expect, architecture was another topic covered in more than a few presentations.
\nOne of our consultants, Alain Chautard, walked us through creating generic components with content projection\non Thursday, using the Dialog and Tabs Components in an example.
Manfred Steyer focused on topics related to Micro-frontend architecture\nand Webpack Module Federation. He discussed Static\nand Dynamic Federation configuration and showed how to share libraries and modules between independent\napplications.
\nIn a similar vein, Adrian Iskandar Espinosa Caballero discussed some advantages of using Micro frontends,\nnamely:
\nBoth speakers presented sample Micro-frontend applications using React, AngularJS, and various versions of\nAngular.
\nThere were also topics related to Monorepos, which have Nx at\ntheir heart. Michael Madsen and Erik Slack presented 20 reasons why you should use Nx.
\nThere was also a session on state management using NgRx as an example. Kate Sky and, in a later session,\nBrandon Roberts talked about some of the best and worst (or suboptimal, at least) practices for using\nNgRx. They also discussed separating smart and presentational components, clean code,\nand state management in a monorepo, using Nx as an example.
\nIn another session, Mike Ryan and Brandon Roberts presented the new v14 version of NgRx and its features,\nsuch as createActionGroup, the new API\nfor Standalone Components,\nand @ngrx/eslint-plugin. The topic of new features\nin NgRx was continued by Marko Stanimirović, discussing\nthe createFeature\nfunction that can help us to reduce repetitive code in selector files.
\nThe session with Pawel\nKozlowski provided some additional insight into Standalone Components. We learned more about their power,\nmotivation, and how they differ from NgModules. We also found how we can use Standalone Components to\ndrastically reduce the number of lines of code and can break inheritance restrictions.
\n![\"Standalone](\"/blog/ng-conf-2022/standalone-components.jpg\")
Manfred Steyer, on the other hand, in his talk on Standalone Components, showed us route handling in an\napplication without NgModules and a recommendation for file and folder structure in such applications.
\nIn his session, Mike Ryan demonstrated ComponentStore\nin action using a sample drawing application as an example. He explained best practices for sharing states\nbetween components, managing streams and lifecycle Subscriptions, decoupling component logic, removing\nresponsibility outside the element, and making them easier to read, write, and test.
We found Ward Bell's session on validating Reactive Forms to be\nparticularly enlightening. He talked about frontend architecture and its role in form validation.\nHe said that it's the model that sets the rules, not the UI; that it's the model that should know if a field\nis required, not the UI; and that it's the model that should understand the relationships between fields in\ndifferent forms on a page. He also demonstrated what the model could look like using the ngc-validate\nlibrary. Ward’s fuchsia-colored outfit also attracted considerable attention. So if you were looking for Ward\nat the conference, you had no problem recognizing him :)
\nIn the last session of the conference, Deborah Kurata discussed best practices for RxJS, mentioned the\ndeclarative approach, and the differences between different\nHigher-Order Maps.
\nThe conference ended with a Q&A session with the Angular Team, during which attendees asked questions for\nnearly an hour. Among other things, they asked about ngUpgrade support for Standalone Components and the\nfuture of Observables in Angular. It was an excellent opportunity for the\ncommunity to learn about the upcoming but more distant plans for the framework.
Each of the three days of the conference presented fascinating information and touched on the essential\naspects of Angular development and its community. There were topics on Angular's history, current best\npractices, and items still in the pipeline.
\nWhat were my takeaways? First, I gained a better understanding of the mechanisms under Angular's hood,\nlearned more about the causes of poor performance in web applications, and the power\nof Standalone Components.
\nI'm particularly looking forward to doing tests using the new NgOptimizedImage module and playing around\nwith RxAngular a bit more. I'm also curious about the new Qwik framework offering, according to Miško\nHevery, the fastest possible page load times.
The only thing I missed was a lack of topics related to hybrid architecture that didn't depend upon using\nMicro frontends. The Angular Team officially\nstopped supporting the AngularJS framework in December 2021,\nbut many projects are stuck on the old framework with no clear path for migrating to the latest version of\nAngular.
\nHopefully, the materials from the conference will be released soon. It's worth checking out the videos when\nthey are published, and you have spare time. Next year, I hope there will be another ng-conf, may it be as\nsuccessful!
\nThank you for your attention!
\nOur team at DevIntent is highly experienced in web development, including framework migration and updates.\nCheck out our offerings or reach out.
", "url": "https://devintent.com/blog/2022-10-15-back-and-better-than-ever-takeaways-from-ng-conf-2022.md", "title": "Back and Better Than Ever - Takeaways from ng-conf 2022", "summary": "Review of interesting sessions at the ng-conf 2022 conference", "date_modified": "2022-10-15T21:20:00.000Z", "tags": [ "angular" ] }, { "id": "blog/2022-10-04-react-to-screen-size-changes-in-angular.md", "content_html": "Imagine that you have an application where you display different content depending on the size of the screen.\nThere are different ways to solve this issue, for example\nwith @media css. Media queries with CSS is really\nhelpful, but if we have business logic to implement depending on the screen size, creating custom classes with\nseparate CSS just to handle these kinds of problems will create unnecessary chaos in our project.
\n![\"Responsiveness](\"/blog/cdk-1/1-react-to-screen-size-changes-in-angular.jpg\")
This is where Angular CDK jumps in. In this article, we will\nfocus on the solution provided by the Angular team, the two main classes\nfrom @angular/cdk/layout\npackage: BreakpointObserver\nand MediaMatcher. We will also build an\napplication that will track changes in the screen size and display different content depending on the\nresolution.
\nLet's get started!
\nThe layout package helps to build responsive UIs that react to screen-size changes. With it, we can catch any\nresize and know when the screen exits or enters a breakpoint.
\nIf you would like to follow along with this article, you will need:
\nIn this article, the examples are based on Angular CLI 14.2.2 and Node 16.13.1.
Let's open a terminal, navigate to the directory where we want to create the project, and type:
\nng new cdk-breakpointobserver-example\nIt will create and initialize a new Angular application.
\nNavigate to the newly created project and install @angular/cdk package:
npm i --save @angular/cdk\nTo use services from Layout Module, we will first need to import it. Lets do that in app.module:
\nimport { NgModule } from '@angular/core';\nimport { BrowserModule } from '@angular/platform-browser';\nimport { BrowserAnimationsModule } from '@angular/platform-browser/animations';\nimport { LayoutModule } from '@angular/cdk/layout';\nimport { MatCardModule } from '@angular/material/card';\n\nimport { AppComponent } from './app.component';\n\n@NgModule({\n declarations: [\n AppComponent\n ],\n imports: [\n BrowserModule,\n BrowserAnimationsModule,\n LayoutModule,\n MatCardModule,\n ],\n bootstrap: [AppComponent]\n})\nexport class AppModule {}\nNow we can start using the available utilities from the LayoutModule.
BreakpointObserver lets you evaluate media queries to determine the current screen size and react to changes\nwhen the viewport size crosses a breakpoint.
export declare class BreakpointObserver implements OnDestroy {\n isMatched(value: string | readonly string[]): boolean;\n\n observe(value: string | readonly string[]): Observable<BreakpointState>;\n ...\n}\nThere are two main methods defined in the class: observe and isMatched. The observe method is used to\nobserve when the screen-size changes between\ndifferent [breakpoints](when the viewport changes between a matching media query). The isMatched tells us\nwhether one or more media queries match the current viewport size.
MediaMatcher is a low-level utility that wraps around\nJavaScript’s matchMedia, which can be\nused to get a native MediaQueryList.
export declare class MediaMatcher {\n matchMedia(query: string): MediaQueryList;\n ...\n}\nAs we can see, it gives us access to the native MediaQueryList object through the public method matchMedia\n.
Let's return to our application. We want to\ntrack the changes of the viewport size, and also list the values of each predefined breakpoint.
\nTo do this, we need to inject BreakpointObserver and MediaMatcher into the class constructor and call\nthe observe and matchMedia methods for class instances.
import {ChangeDetectionStrategy, Component, OnInit} from '@angular/core';\nimport {BreakpointObserver, Breakpoints, BreakpointState, MediaMatcher} from '@angular/cdk/layout';\nimport {Observable} from 'rxjs';\n\n@Component({\n selector: 'app-root',\n templateUrl: './app.component.html',\n changeDetection: ChangeDetectionStrategy.OnPush,\n})\nexport class AppComponent implements OnInit {\n breakpointsInfo: {name: string, value: MediaQueryList}[] = [];\n breakpointState: Observable<BreakpointState> | undefined;\n xSmall: string = Breakpoints.XSmall;\n small: string = Breakpoints.Small;\n medium: string = Breakpoints.Medium;\n large: string = Breakpoints.Large;\n xLarge: string = Breakpoints.XLarge;\n webLandscape: string = Breakpoints.WebLandscape;\n\n constructor(public breakpointObserver: BreakpointObserver, private mediaMatcher: MediaMatcher) {}\n\n ngOnInit(): void {\n this.breakpointsInfo = this.getBreakpointsInfo();\n\n this.breakpointState = this.breakpointObserver.observe([\n Breakpoints.XSmall,\n Breakpoints.Small,\n Breakpoints.Medium,\n Breakpoints.Large,\n Breakpoints.XLarge,\n Breakpoints.WebLandscape,\n Breakpoints.WebPortrait,\n ])\n }\n\n getBreakpointsInfo(): {name: string, value: MediaQueryList}[] {\n return [\n Breakpoints.XSmall,\n Breakpoints.Small,\n Breakpoints.Medium,\n Breakpoints.Large,\n Breakpoints.XLarge,\n Breakpoints.Web,\n Breakpoints.WebLandscape,\n Breakpoints.WebPortrait,\n Breakpoints.Handset,\n Breakpoints.HandsetLandscape,\n Breakpoints.HandsetPortrait,\n Breakpoints.Tablet,\n Breakpoints.TabletLandscape,\n Breakpoints.TabletPortrait\n ].map((breakpoint, index) => ({name: Object.keys(Breakpoints)[index], value: this.mediaMatcher.matchMedia(breakpoint)}));\n }\n}\nThe observe method returns Observable\nof BreakpointState type, that we need to\nsubscribe to for observing when the viewport of your application changes. We can do this manually in the\ncomponent class with subscribe method, or in\nthe component template with async pipe.
\n<div *ngIf=\"breakpointState | async as state\" style=\"display: flex; gap: 10px\">\n <h2 *ngIf=\"state.breakpoints[xSmall]\">Breakpoint: Extra Small</h2>\n <h2 *ngIf=\"state.breakpoints[small]\">Breakpoint: Small</h2>\n <h2 *ngIf=\"state.breakpoints[medium]\">Breakpoint: Medium</h2>\n <h2 *ngIf=\"state.breakpoints[large]\">Breakpoint: Large</h2>\n <h2 *ngIf=\"state.breakpoints[xLarge]\">Breakpoint: Extra Large</h2>\n <h2>Orientation: {{ breakpointObserver.isMatched(webLandscape) ? 'Landscape' : 'Portrait' }}</h2>\n</div>\nIt is worth adding that we can listen for non-standard breakpoints that we define ourselves:
\nthis.breakpointObserver.observe(['(min-width: 500px)'])\nTo additionally display information about the value of\nindividual Breakpoints, we need to\nloop through breakpointsInfo collection and display the values of the name and value property:
<mat-card>\n <mat-card-title>Breakpoints ranges</mat-card-title>\n <mat-card-content>\n <ul>\n <li *ngFor=\"let breakpoint of breakpointsInfo\">\n <p><strong>{{breakpoint.name}}</strong>: {{breakpoint.value.media}}</p>\n </li>\n </ul>\n </mat-card-content>\n</mat-card>\nAs a result, we should see the following effect:
\n![\"Breakpoints](\"/blog/cdk-1/2-resolution-and-breakpoints-info.jpg\")
We saw how to react to viewport size changes using BreakpointObserver and MediaMatcher classes. We can\neasily handle the elements of business logic, not being limited only to files with the styles, but also have\ncontrol over them in the component and its template.
Source code with a working application described in the article can be found on\nthe GitHub repository.
\nThank you for your attention!
\nOur team at DevIntent is highly experienced in web development, including framework migration and updates.\nCheck out our offerings or reach out.
", "url": "https://devintent.com/blog/2022-10-04-react-to-screen-size-changes-in-angular.md", "title": "React To Screen-size Changes In Angular", "summary": "Using BreakpointObserver with MediaQuery to respond to screen-size changes", "date_modified": "2022-10-04T00:00:00.000Z", "tags": [ "angular", "angular-cdk" ] }, { "id": "blog/2022-07-29-testing-angular-applications-with-playwright.md", "content_html": "Playwright is an excellent option for end-to-end (E2E) testing your Angular applications if you're looking to transition away from Protractor. According to this summary, it's the third most popular E2E tool in the Angular community—just after Cypress and Protractor.
\nPlaywright is developed by Microsoft—the company that brought us TypeScript. It has a large following on GitHub; with 40k stars, and almost 2k forks, it is one of the most popular open-source projects for E2E testing.
\nPlaywright runs tests and controls the browser from the outside. The test runner runs the test scripts, controls the browsers via API, and doesn't share the execution context with the application—the same approach as in Protractor or Selenium.
\nBecause Playwright tests run outside the browser, there is a bigger choice of languages in which you can write your tests: you’re not restricted to just JS or its flavors like in Protractor, Cypress, or Nightwatch.js. Currently, you can write your test in:
\nThis provides the flexibility to adapt the tests to the project and pick the language to get the most out of the skills you have available within your team.
\nPlaywright allows you to run your tests in major browsers:
\nPlaywright emphasizes speed, and according to this article, they deliver on that.
\nLet's take a look at an example test suite in Playwright.
\nThe application we will test is the final step from the official Angular tutorial Tour of Heroes. You can find the repository with the example code here.
\nAn easy way to initialize the Playwright tests in a project is to run:
\n![\"npm](\"/blog/playwright-1/1-init.png\")
For easy access to running the tests, let's update package.json:
![\"package.json](\"/blog/playwright-1/2-diff.png\")
With this change, npm run e2e will run Playwright with the default configuration—running tests on three headless browsers: Chromium, Firefox, and WebKit. Headless runs are faster and happen in isolation from the user, but they make debugging tests more difficult. For this, we have npm run e2e:debug, starting with only one visible browser.
Example tests in tests/example.spec.ts:
import { test, expect, type Page } from '@playwright/test';\n\ntest.describe('Tour of Heroes pages', () => {\n test('should load default route', async ({page}) => {\n await page.goto('http://localhost:4200');\n\n await expect(page).toHaveURL(/\\/dashboard$/);\n });\n\n test('should allow edits', async ({page}) => {\n await page.goto('http://localhost:4200');\n\n await page.locator('[data-test=\"detail-link\"]').first().click();\n\n await expect(page).toHaveURL(/\\/detail\\/\\d+/);\n\n await page.locator('#hero-name').fill('lorem ipsum');\n\n await page.locator('[data-test=\"save-button\"]').click();\n\n await expect(page.locator('[data-test=\"detail-link\"]').first()).toContainText('lorem ipsum');\n });\n\n test('should search for heroes', async ({page}) => {\n await page.goto('http://localhost:4200');\n\n await page.locator('#search-box').fill('nice');\n\n await expect(page.locator('[data-test=\"search-result-link\"]')).toHaveCount(1);\n\n await page.locator('[data-test=\"search-result-link\"]').click();\n\n await expect(page).toHaveURL(/\\/detail\\/12/);\n });\n\n test('should delete heroes', async ({page}) => {\n await page.goto('http://localhost:4200/heroes');\n\n await expect(page.locator('.delete')).toHaveCount(9);\n\n await page.locator('.delete').first().click();\n\n await expect(page.locator('.delete')).toHaveCount(8);\n });\n\n test('should add heroes', async ({page}) => {\n await page.goto('http://localhost:4200/heroes');\n\n await page.locator('#new-hero').fill('Lorem Ipsum');\n\n await page.locator('.add-button').click();\n\n await expect(page.locator('.delete')).toHaveCount(10);\n });\n});\nThe way of organizing tests in Playwright is similar to how it’s done in Protractor or Cypress. The API is returning promises, and we use await to ensure that each step is done executing before the next one is started.
To run tests, we need to start the application server in the background:
\n$ npm run start\n\n> angular.io-example@0.0.0 start\n> ng serve\n\n…\n\n** Angular Live Development Server is listening on localhost:4200. Open your browser on http://localhost:4200/ **\n\n…\n\n✔ Compiled successfully.\nWith the server running, we can run all tests with:
\n![\"npm](\"/blog/playwright-1/3-run.png\")
As you see, setting E2E tests with Playwright for Angular applications is pretty straightforward. Thanks to its broad language support, you can choose a language depending on what skills are available in your team. E2E tests are an essential tool to maintain a high quality of an application in fast-moving teams.
\nOur team at DevIntent is highly experienced in Angular development, testing, and software quality. If you'd like to chat about how we can help you, please contact us at sales@devintent.com.
", "url": "https://devintent.com/blog/2022-07-29-testing-angular-applications-with-playwright.md", "title": "Testing Angular Applications With Playwright", "summary": "A brief introduction to writing end-to-end tests with Playwright.", "date_modified": "2022-07-29T00:00:00.000Z", "tags": [ "angular", "testing" ] }, { "id": "blog/2022-01-25-angularjs-end-of-life-what-next.md", "content_html": "When AngularJS was first launched in 2010 it was ground-breaking for web development. After more than a\ndecade, millions of projects around the world still rely on this framework.\nAngularJS is still one of the most popular frontend frameworks today. In StackOverflow's 2021 survey which\nincluded responses from over 50,000 developers, nearly\n13% said they are still using AngularJS.
\n![\"End](\"/large-images/end-of-road.jpg\")
On July 1, 2018, AngularJS\nentered its Long-term Support (LTS) period. The\nsupport was originally scheduled to end on June 30th, 2021.
\nGiven the COVID-19 pandemic and its impact on teams migrating from AngularJS, the Google team extended the\nLTS for another 6 months, until December 31st, 2021.
\nAs of January 1st, 2022 AngularJS has reached End-of-Life. You can read more about it on the official\nAngular blog in\nDiscontinued Long Term Support for AngularJS.\nFor those who are still using this framework, it will have a profound impact on their development and support\nplans. AngularJS will not receive patches for security vulnerabilities or breaking issues caused by new\nbrowser releases.
\nNow that AngularJS has reached its End-of-Life, AngularJS applications will continue to function, at least\nuntil the next breaking browser change happens.
\nNevertheless, using old versions of the framework is critical to the security of your application and your\nuser's data. Since security patches will no longer be provided by Google, your business and your customers may\nbe vulnerable to new / previously unknown security threats. Before a major vulnerability is disclosed to the\npublic or there is an announcement that it is being exploited in the wild, you will need to have a mitigation\nplan in place.
\nIf your project is based on an older version of AngularJS, consider upgrading to AngularJS 1.8.2. The latest\nversion of AngularJS improves security, imposes a component-based architecture, fixes a few bugs and will make\nthe process of migrating to modern Angular much faster. If you aren't on AngularJS 1.8.0, or later, then\nyour application and your users are already exposed to a\nrange of security vulnerabilities, including Cross-site Scripting (XSS)\nattacks. Get protected now, by updating to the latest AngularJS version, if you haven't already done so!
You can get Extended Long-term Support via XLTS for AngularJS from XLTS.dev.\nThis will allow you to continue developing or maintaining your application while using supported software.\nThis means that you will receive fixes for security vulnerabilities and breakages to browsers or jQuery when\nthey occur. If you have regulatory or other compliance obligations, this can help you stay compliant and\nget the customer approvals that your business needs.
\nIf you're ready to start migrating your legacy AngularJS application to modern Angular,\na good first step is to refactor your application step-by-step, module by module, creating a\nhybrid AngularJS/Angular application. Using this hybrid approach minimizes risk since small chunks of your\nexisting application can be migrated and tested. Using the ngUpgrade tool, you can mix and match AngularJS\nand Angular code in the same application and ensure their smooth cooperation.
If your current AngularJS application is small and the business logic and other requirements are\nwell-documented, you may be able to perform a full re-write in a modern framework\n(e.g. Angular, React, Vue, etc.) without running into major issues. A full rewrite is a riskier approach for\nlarge or medium-sized applications. Careful planning, selection of the right tools/technologies, and building\na team with the right skill-sets is necessary to avoid broken/missing functionality, costly delays, or even\ncomplete project failure.
\nIf you require expert assistance or are unsure how to identify the best solution for your project,\nDevIntent has the expertise to help. Contact us at\nconsulting@devintent.com to get in touch. We have worked with many\nenterprise and mid-sized companies since 2013 to help them update and migrate their AngularJS 1.x based\napplications. We can help make your Angular or AngularJS project a success.
We’ve worked on projects like: Angular, AngularJS, Angular CDK, Angular Material, AngularJS Material, and the\nAngular CLI.
\nApply today at careers@devintent.com to join us in moving the Angular\ncommunity forward from AngularJS.\n
", "url": "https://devintent.com/blog/2022-01-25-angularjs-end-of-life-what-next.md", "title": "AngularJS End-of-Life - What Next?", "summary": "What options are available now that Google has dropped support for AngularJS?", "date_modified": "2022-01-25T00:00:00.000Z", "tags": [ "angularjs" ] }, { "id": "blog/2021-12-30-angular-13-is-out.md", "content_html": "\n\nAngular v13 is here 🎉#ngUpdate for built-in improvements like:
— Angular (@angular) November 4, 2021
- Faster prod builds
- Enhanced component a11y
- Improved test times and debugging
- Modern Angular Package Format
Read more:
📚 https://t.co/dx1HzBY9z6
Join us Friday at 10am PST:
📅 https://t.co/6GGtgkJDpl pic.twitter.com/ZZqIpja50M
It's been six months since the last major version of the Angular framework was released. A completely new\nversion of Angular has just been released.
\nIn this article we'll look at some features and updates that will help you create amazing applications. We\nwill go through a few optimizations of the Ivy engine. We will also talk about what is being deprecated and\nbriefly discuss the process of migrating the application to Angular v13.
\nSo let's get started!
\nWith the release of the new version, the Angular team provides\na complete guide to upgrade from previous versions. By following\nthe guide, you shouldn't have any problems with getting migrated to the latest version.
\nIf you are using Nx, please follow the guidelines provided by\nthe Nwrl team. By running nx migrate latest, you will also update Angular and all its dependencies.
In the latest release of Angular, there are also changes in the dependencies of the framework. Angular v13\nintroduces TypeScript 4.4 support, which means that we can now\nuse its new features.\nSupport for older versions of TypeScript has been dropped.
\nMoreover, version 7.4 is now the default version for RxJs. To learn more about the changes from version 6 to\nversion 7, please read this article.
\nAdditionally, Angular v13 has dropped support for NodeJS versions below v12.20.0 and has introduced\nsupport for NodeJS >=16.10.
\nAnd it happened. IE11 is no longer supported by Angular v13. This is one of the most important pieces of news\nfor this release. Dropping support for IE11 is a good thing - it means Angular gets to fully embrace the Web\nAPIs of modern browsers. It also means that we no longer have to include polyfills for IE, which makes\napplications lighter and load faster than in previous versions of Angular. It is worth noting that the\nmigration process described previously will automatically remove polyfills for IE.
\nThe Angular team put out an RFC (request for comments) about\ndropping IE11 support, and the feedback they received was overwhelmingly in favor of doing so.
\n![\"Emote](\"/large-images/responses-rfc.png\")
Note that Angular 12 will continue to support IE11 until November 2022.
\nAs promised in past announcements, Angular version 13 no longer supports the old rendering View Engine. For\nthe average Angular dev, this doesn't mean much (other than reaping the benefits of a more performant\nframework). For library builders in Angular, though, this is a big deal.
\nAs mentioned in the official announcement, removing View Engine also means that Angular can reduce its\nreliance on ngcc (Angular compatibility compiler) in the future, and\nteams can look forward to faster compilation because metadata and summary files are no longer included.
\nAs mentioned in the official announcement,\nthe Angular Package Format (APF) has been streamlined and\nmodernized to better serve developers. To streamline the APF in Angular v13, older output formats such\nas CommonJS (CJS) and UMD have been removed. Thanks to this change, the whole Web community will be better\noff once ES Modules (ESM) are used everywhere.
\n\nAngular v13 will ship with the most modern version of APF (Angular Package Format): ES Modules+ES2020
— Igor Minar (@IgorMinar) November 2, 2021
If you've ever maintained an npm library, you know how hard it is to come up with the right package format that is modern & works for most use-cases! 🚀https://t.co/A8HPqixfKk
The Angular team has also updated the APF to support Node Package Exports. This will help developers from\ninadvertently relying on internal APIs that may change.
\nIt is now time for Angular library authors to stop using enableIvy: false, and to instead\nuse compilationMode: partial (in tsconfig.prod.json), as recommended by Younes.
\n\n⏳ tired of ngcc?
— Younes (@yjaaidi) November 2, 2021
🚀 get ready for #Angular 13!
🧹 meanwhile, fellow library authors, let's move from "enableIvy: false" to "compilationMode: partial"
Cf. https://t.co/8ahrmiUp5R#javascript pic.twitter.com/iXL541Ui1Z
The partial compilation mode is a partial-Ivy code format that is stable between different versions of\nAngular, and thus safe to publish to npm. Angular code that uses this partial format is processed during the\nbuild of the application using the same version of the Angular compiler. The benefit is that both the\napplication and its libraries rely on a single version of Angular, removing potential compatibility issues.
\n\n\nExisting libraries will be automatically migrated to use “partial” compilation mode and some metadata previously required for the legacy View engine will be removed.
\n
To learn more check out\nthe official guidelines for library\nauthors.
\nIvy enables a simpler way to create dynamic components. Angular no longer requires component factories to\ndynamically create components. Ivy creates the opportunity to instantiate the component\nwith ViewContainerRef.createComponent without creating an\nassociated factory. So, instead of:
\n@Directive({...})\nexport class CustomyDirective {\n constructor(\n private viewContainerRef: ViewContainerRef,\n private componentFactoryResolver: ComponentFactoryResolver\n ) {\n }\n\n createCustomComponent() {\n const componentFactory = this.componentFactoryResolver.resolveComponentFactory(CustomComponent);\n this.viewContainerRef.createComponent(componentFactory);\n }\n}\nWe can now write:
\n@Directive({...})\nexport class CustomDirective {\n constructor(private viewContainerRef: ViewContainerRef) {\n }\n\n createCustomComponent() {\n this.viewContainerRef.createComponent(CustomComponent)\n }\n}\nAs we can see, the new approach requires much less boilerplate code!
\nWith this release, Angular supports the use of persistent build cache by default,\nas requested by the community. The persistent build\ncache is a feature that caches build results on disk (under the .angular/cache folder). This results in up\nto 68% improvement in compilation speed.
In order to enable this feature in existing projects that have been upgrading to v13, we need to add the\nfollowing configuration to angular.json:
{\n \"$schema\": \"...\",\n \"cli\": {\n \"cache\": {\n \"enabled\": true,\n \"path\": \".cache\",\n \"environment\": \"all\"\n // other supported values: \"ci\" and \"local\"\n }\n }\n}\nWe can also disable this feature (which is not recommended) with ng config cli.cache.enabled false.
If we need to clear the cache, we should delete the .angular / cache folder.
For those who use esbuild as a build tool, there is good news as well. The\nperformance has been improved. The Angular team has introduced esbuild, which now works\nwith terser to optimize global scripts. In addition, ESBuild supports CSS sourcemaps\nand can optimize global CSS, as well as optimizing all style sheets.
\nSetting the routerLink directive value to null or undefined will completely disable navigation. Recall\nthat in the previous version, the null and undefined inputs for the routerLink directive were\ninterpreted as an empty string.
A new output for the routerLinkActive directive called isActiveChange has been added. It emits\nwhenever the link becomes active or inactive.
The loadChildren property in the route definition no longer supports string values. It's been deprecated for\na while now. This has been replaced by the ESM dynamic import statement.
A new property has been added to Router public API
\nRouterModule.forRoot(routes, {canceledNavigationResolution: 'computed'});\nRouter now also provides new outputs for subscribing when an outlet gets attached/detached.
\nRouterTestingModule TestBed.configureTestingModule({\n imports: [RouterTestingModule],\n providers: [{provide: RouteReuseStrategy, useClass: AttachDetachReuseStrategy}]\n });\nIn this version, a little more attention is paid to Angular Forms, improving the security of reactive forms.\nLet's take a look at the changes.
\nA specific type called FormControlStatus has been introduced, which is the union type of all possible status\nstrings for form controls: 'VALID' | 'INVALID' | 'WAITING' | 'OFF'. Until now, we could not use Typescript\nchecking because AbstractControl.status was entered as a string and AbstractControl.statusChanges\nwas Observable<any>.
This is a breaking change! As mentioned in the release notes, this can break applications if an invalid form\nstatus string is used or if statusChanges events were something other than strings.
New form methods have been added to AbstractControl:
addValidators: Add one or more synchronous validator(s) to the control, without affecting other validatorssetValidators: Sets one or multiple validators by overriding the registered ones. For removing all\nregistered validators we can pass a value of nullhasValidator: Determines whether a validator or validators array has a given validatorremoveValidators: Remove synchronous validators from this controlAll of these methods also have an async version: addAsyncValidators, setAsyncValidators\n, removeAsyncValidators, and hasAsyncValidator.
These new methods provide us with more control over the validation process. We can now easily add/remove\nsynchronous and asynchronous validators.
\nAngular now\nsupports autocompletion for string literal union types\n. The language service of Angular is now able to automatically insert the optional chaining operator (i.e.,\n?.) when property access (i.e., .) is done on a nullable symbol.
\nAlso, the fullTemplateTypeCheck compiler option has been deprecated. Instead, we should use strictTemplates\n.
The new version of Angular has also resulted in significant improvements and changes to the components of\nAngular Material.
\nAll MDC-based components have been assessed to meet elevated a11y standards in areas such as contrast, tactile\ntargets, ARIA, and more. For example let’s compare touch target sizes. The sizes on the right are the new\nsizes.
\n![\"Comparison](\"/large-images/touch-target-sizes-comparation.png\")
or for better support for high contrast mode for many components:
\n![\"Material](\"/large-images/components-in-high-contrast-mode.png\")
It’s always a pleasure to see large organizations put energy into improving accessibility.
\nThere are also a few changes for Angular Material.
\nIt is now possible to define content sections in test harnesses for the Dialog component. Also, a new\ninjection token called MAT_PROGRESS_BAR_DEFAULT_OPTIONS has been added to the progress bar. It can be used\nto configure the default options as follows:
provide: MAT_PROGRESS_BAR_DEFAULT_OPTIONS,\nuseValue: {\n mode: 'buffer',\n color: 'warn'\n}\nTogether with Angular v13, TestBed has also been improved. It now takes better care of tearing down test\nmodules and environments after each test. The DOM is now cleaned up after every test, avoiding side effects.\nOverall, tests should execute faster, use less memory, and be less interdependent.
\nThe automatic teardown functionality was an opt-in feature since Angular v12.1.0 and is now enabled by default.\nAs mentioned in the announcement, this behavior can be configured for the entire test suite via\nthe TestBed.initTestEnvironment method:
beforeEach(() => {\n TestBed.resetTestEnvironment();\n TestBed.initTestEnvironment(\n BrowserDynamicTestingModule,\n platformBrowserDynamicTesting(),\n {\n teardown: {destroyAfterEach: true}\n }\n );\n});\nOr it can be configured per module by updating the TestBed.configureTestingModule method:
beforeEach(() => {\n TestBed.resetTestEnvironment();\n...\n TestBed.configureTestingModule({\n declarations: [TestComp],\n teardown: {destroyAfterEach: true}\n });\n});\nThis allows us to approach testing differently depending on the situation.
\nThe new release of Angular introduced a lot of new improvements and minor changes, but also unlocked the way\nto the critical ones, such as the optional NgModules.\nViewEngine is gone for good and Ivy has become ubiquitous.
\nThis is another release that improves runtime performance, shortens build time, simplifies API, and improves\ntests.
\nFinally, I encourage you to check\nthe full list of changes.
\nUntil next time!
\n![\"Transamerica](\"/large-images/transamerica-pyramid.jpg\")
This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\n.scss files directly in your build, you will need to switch\nfrom the deprecated node-sass package to the sass package for compiling your Sass.marked Markdown rendering (441a912)Thank you to the contributors who helped with the v1.2.4 release:
\n![\"Splaktar\"](\"https://avatars1.githubusercontent.com/u/3506071?v=4&s=117\")
![\"bjarkler\"](\"https://avatars.githubusercontent.com/u/66124740?v=4&s=117\")
![\"superheri\"](\"https://avatars.githubusercontent.com/u/30275781?v=4&s=117\")
This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThank you to the contributors who helped with the v1.2.3 release:
\n![\"atfzls\"](\"https://avatars2.githubusercontent.com/u/55975318?v=4&s=117\")
This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a patch release that includes bug fixes and enhancements.
\nThank you to the contributors who helped with the v1.2.2 release:
\n![\"FreedCapybara\"](\"https://avatars2.githubusercontent.com/u/7003723?v=4&s=117\")
![\"shishkinilya\"](\"https://avatars0.githubusercontent.com/u/20458127?v=4&s=117\")
![\"kylekatarnls\"](\"https://avatars1.githubusercontent.com/u/5966783?v=4&s=117\")
![\"natete\"](\"https://avatars2.githubusercontent.com/u/4098303?v=4&s=117\")
This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a patch release that includes bug fixes.
\nmd-calendar when it is used in outside of a datepickermd-select when used with the md-select-header attribute\nand without the multiple attribute, closes when clicking the filter inputmd-select would be black instead of using the\ntheme colormd-icon has been updated to match the behavior defined in the docs when you provide\naria-label=\"\" or alt=\"\", i.e. apply aria-hidden=\"true\"md-list-items that are clickable by screen readersspace key-webkit-touch-callout: none; style on your app's\nhtml, bodyThank you to the contributors who helped with the v1.2.1 release:
\n| ![\"mmalerba\"](\"https://avatars1.githubusercontent.com/u/14793288?v=4&s=117\")
![\"josephperrott\"](\"https://avatars2.githubusercontent.com/u/10864441?v=4&s=117\")
![\"cgx\"](\"https://avatars2.githubusercontent.com/u/1088448?v=4&s=117\")
This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a patch release that includes bug fixes.
\nThis is the last planned patch release for the 1.1.x release branch. Future patch releases\nwill be based upon the 1.2.x release branch.
Thank you to the contributors who helped with the v1.1.26 release:
\n| ![\"mmalerba\"](\"https://avatars0.githubusercontent.com/u/14793288?v=4&s=117\")
This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a patch release that includes bug fixes.
\nmd-select when used with the md-select-header attribute\nand without the multiple attribute, closes when clicking the filter inputmin-date validation issues in GMT+X timezones1.1.26\nvia PR #12006.Thank you to the contributors who helped with the v1.1.25 release:
\n| ![\"jelbourn\"](\"https://avatars3.githubusercontent.com/u/838736?v=4&s=117\")
This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a major release that includes breaking changes, deprecation removals, enhancements,\nand bug fixes.
\nmd-inline-form class.auto-horizontal-margin($selector)) for more easily laying out components\nin layout=\"row\" containers.min-date validation in md-datepicker is broken for GMT+T timezones\n#11963.md-autocomplete, when the options panel is visible and the Escape key is pressed, has changed. md-escape-options now defaults to 'clear' instead of 'blur clear'. This better aligns with the WAI-ARIA Authoring Practices as the focus is not sent to another element (like the <body>) when the Escape key is pressed.If you want to restore the previous behavior, add the following to your md-autocomplete components:
md-escape-options=\"blur clear\"\nmd-auto-focus directive. It was deprecated in favor of md-autofocus. Please see the md-autofocus Docs for examples.md-button's internal horizontal padding has changed from 6px to 8px to match the Material Design spec. This may affect the layout of portions of your application where md-button, md-datepicker, or md-toast with actions are used.If you are using our SCSS files, you can override this back to the default, or another value, in your app's SCSS files:
\n$button-left-right-padding: rem(0.6); // For 6px horizontal padding\nclass=\"md-actions\" inside of an md-card template. This is deprecated in favor of using the <md-card-actions> element.md-checkbox labels, then you may need to remove or change that code now. This is because we automatically detect <a> tags in these labels and re-render them in an accessible way.md-checkbox has been updated to align with the Material Design specification. Additionally, many new Sass variables have been added for customizing the size and spacing of md-checkbox. The md-dense class is now supported. After updating to this version, you may need to adjust the layout of your app due to the larger touch-friendly size of checkbox. You may also want to make use of md-dense in cases where space is limited.$chip-font-size was reduced to 13px from 16px. $chip-remove-padding-right was increased to 28px from 22px. These changes may cause your chips to have a smaller, denser layout now. In certain scenarios, this may require minor changes to your app's layout. You can change these variables back to their old values if your app consumes Sass. Additionally, the remove chip icon has been changed, but you can use the custom chip template demo as a guide to changing back to the old icon, if desired.md-on-append attribute. It was deprecated in favor of md-transform-chip or the simple notifier md-on-add. Please see the md-chips Demos for examples of using md-transform-chip.MdChipsCtrl.selectAndFocusChip() function has been removed.\nMdChipsCtrl.selectAndFocusChipSafe() should be used instead.class=\"md-actions\" inside of an md-dialog template. This was deprecated in favor of using the <md-dialog-actions> element..content('string') methods and options. These were deprecated in favor of .textContent('string') and .htmlContent('sanitized-string')' methods and their associated options. Please note that use of .htmlContent requires that the ngSanitize module be loaded.If you have
\nalert = $mdDialog.alert().content('This is an example.');\nIt needs to be changed to
\nalert = $mdDialog.alert().textContent('This is an example.');\nIf you have
\nalert = $mdDialog.alert({\n content: 'This is an example.',\n});\nIt needs to be changed to
\nalert = $mdDialog.alert({\n textContent: 'This is an example.',\n});\ninput-container: md-input and md-select inside of md-input-containers have been updated to use indentation that is consistent with the spec (aligned to the left in LTR and the right in RTL). This may cause some minor layout issues in apps that depended upon the previous 2px padding inside of md-input-container.
layout: The way that margins are applied to md-checkbox, md-input-container, md-radio-group, and md-select has been changed. You can now use the $default-horizontal-margin Sass variable to override the default 16px horizontal margin size. As part of this, md-radio-buttons inside of layout=\"row\" containers are now aligned vertically with other content as they no longer have a 16px margin-bottom. If you have previously added custom styles, to your components inside of a row layout, in order to give them extra margin-right in LTR or margin-left in RTL, you will need to re-evaluate those styles. In most cases, they can now be removed.
layout: Removed the deprecated, undocumented *-lt-* layout attributes and classes. This includes the following attributes and their matching classes, which have been giving deprecation warnings since 2015:
layout-lt-md
layout-lt-lg
flex-lt-md
flex-lt-lg
layout-align-lt-md
layout-align-lt-lg
flex-order-lt-md
flex-order-lt-lg
flex-offset-lt-md
flex-offset-lt-lg
hide-lt-md
hide-lt-lg
show-lt-md
show-lt-lg
list: md-list with the md-dense class has been updated to align with the Material Design specification. This means that md-list-items heights have changed when using md-dense. The md-dense-disabled class is now supported on md-list. After updating to this version, you may need to adjust the layout of your app if you use md-dense with md-list or customize the layout of md-checkboxs within md-list-items.
\\$mdCompilerProvider: The deprecated $mdCompilerProvider.respectPreAssignBindingsEnabled() API has been removed.\nWe no longer respect AngularJS's $compileProvider.preAssignBindingsEnabled() value as this API was removed\nin AngularJS 1.7.0.
If you had the recommended configuration for AngularJS 1.6.x:
\n$compileProvider.preAssignBindingsEnabled(false);\n$mdCompilerProvider.respectPreAssignBindingsEnabled(true);\nThen you should remove both of these calls as they are now the defaults in AngularJS 1.7.0\nand AngularJS Material 1.2.0.
If you had the recommended configuration for AngularJS 1.7+:
\n$mdCompilerProvider.respectPreAssignBindingsEnabled(true);\nThen you should remove this call as it is now the default in AngularJS Material 1.2.0.
If you were using a backwards-compatible configuration for AngularJS 1.6+:
\n$mdCompilerProvider.respectPreAssignBindingsEnabled(false);\nThen you will need to remove this call and may need to refactor your Controllers for\nAngularJS Material components like $mdDialog, $mdPanel, $mdToast, or $mdBottomSheet.
For example:
\n $mdDialog.show({\n locals: {\n myVar: true\n },\n controller: MyController,\n bindToController: true\n }\n function MyController() {\n // No locals from Angular Material are available. e.g myVar is undefined.\n // You would need to move anything accessing locals in here to $onInit().\n }\n MyController.prototype.$onInit = function() {\n // Bindings are now available in the $onInit lifecycle hook.\n }\n$mdOpenMenu API. It was deprecated in favor of $mdMenu.open.MdPanelRef.addClass(), MdPanelRef.removeClass(), and MdPanelRef.toggleClass() functions have been removed. These were deprecated in 2016 in favor of using the panelContainer or panelEl JQLite elements that are referenced in the MdPanelRef object.ngMultiple has been renamed to mdMultiple to make it clear that this\nAPI is provided by AngularJS Material and not by AngularJS.If you had:
\n<md-select ng-multiple=\"expression\">...</md-select>\nYou need to change to:
\n<md-select md-multiple=\"expression\">...</md-select>\n$media service in md-is-locked-open. This was deprecated in favor of the $mdMedia service. The functionality is the same and only a rename to the current name of the service is required.md-sidenav-focus directive. It was deprecated in favor of md-autofocus. Please see the md-autofocus Docs and md-sidenav Basic Usage Demo for examples.min-width and padding which matches the Material Design specification. For width, this is 72px on xs screens and 160px on all other screens. For left and right padding, this is now 12px instead of 24px. If your app needs to have tabs which are smaller than the spec, you will need to override md-tab-item's min-width and md-tab's padding styles.$mdThemingProviderTheme.primaryColor() and the related accent/warn/background APIs. These were deprecated in favor of $mdThemingProviderTheme.primaryPalette() (and accent/warn/background) in 2015 and they have been logging warnings when used since then.1.2.0. There may be edge cases in your app or custom styles that need to be updated to meet accessibility guidelines.If you find significant accessibility issues after updating, please report them to us. In 1.2.x, we have a lot more control over our component theming in regards to hues and opacities.
If your app is using a custom palette, whether based on a copy of default palette or not, we encourage you to evaluate that your contrast configuration meets the WebAIM guidelines. Please review our guide on Defining Custom Palettes for details.
\n$mdToast.show()'s position behavior has been updated to be consistent with the documentation. If you relied on the previously undocumented behavior where it defaulted to top left instead of bottom left, you will need to update your app.Change your code from this:
\n $mdToast.show(\n $mdToast.simple()\n .textContent('Simple Toast!'))\n .then(...\nTo this:
\n $mdToast.show(\n $mdToast.simple()\n .textContent('Simple Toast!')\n .position('top left'))\n .then(...\ncontent() and updateContent() methods have been removed.If you had:
\n$mdToast.show($mdToast.simple().content('This no longer works.'));\nYou will need to change to:
\n$mdToast.show($mdToast.simple().textContent('This works.'));\nIf you had:
\n$mdToast.updateContent('This no longer works.');\nYou will need to change to:
\n$mdToast.updateTextContent('This works.');\nIf you had:
\n$mdToast.show($mdToast.simple({ parent: parent, content: 'This no longer works.', theme: 'some-theme', capsule: true }));\nYou will need to change to:
\n$mdToast.show($mdToast.simple({ parent: parent, textContent: 'This works.', theme: 'some-theme', capsule: true }));\nThank you to the contributors who helped with the v1.2.0 release:
\n| ![\"clshortfuse\"](\"https://avatars3.githubusercontent.com/u/9271155?v=4&s=117\")
![\"oliversalzburg\"](\"https://avatars2.githubusercontent.com/u/1658949?v=4&s=117\")
![\"batsauto\"](\"https://avatars3.githubusercontent.com/u/17678174?v=4&s=117\")
![\"wagnermaciel\"](\"https://avatars1.githubusercontent.com/u/25158423?v=4&s=117\")
| ![\"tomaszgrabowski\"](\"https://avatars0.githubusercontent.com/u/6688790?v=4&s=117\")
This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a patch release that includes bug fixes.
\n$mdPanel animation bugsng-model-options on to calendar so that they both use the same timezone settingsmd-datepicker to work with a custom config via $mdDateLocaleProvider, including MomentJSmin-date validation in md-datepicker is broken for GMT+T timezones\n#11963. Planned for in 1.1.25.md-select using md-select-header closes on mouse click when not using multiple\n#11969. Will be fixed in 1.1.25.ng-model-options timezone w/ MomentJS and datepicker now passes ng-model-options on to calendar (12562b0), closes #11945 #10598Thank you to the contributors who helped with the v1.1.24 release:
\n|
This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a patch release that includes bug fixes.
\nmd-month-filter API to md-datepicker and md-calendarmd-date-filter API$onDestroy hook in $mdCompiler$mdPanel animationsmd-select including bringing back support for ng-selected on md-optionmd-calendar support for specifying timezone in ng-model-optionsmd-datepicker throws exceptions if you specify a custom config via $mdDateLocaleProvider\n#11945. Fixed in 1.1.24.min-date validation in md-datepicker is broken for GMT+T timezones\n#119631.1.24.md-select using md-select-header closes on mouse click when not using multiple\n#11969. Will be fixed in 1.1.25.md-date-filter only evaluates first day of month (3d5ff5d), closes #11703$onDestroy hook not called (8bb1d98), closes #11847$validate has run (11f65e3), closes #10360'&&' not a primary expression (#11940) (1bd1a97), closes #10935md-list-item padding for clickable items (f7d9027), closes #10384md-focused not removed from options on panel close (5a7e967), closes #11927ng-selected on md-options (546bd84), closes #11914onRemove doesn't return a Promise in some cases (e625a9c), closes #10379md-scroll-shrink conflicts with md-select in toolbar (1ed54bb), closes #10413 #9871inline to inline-block to account for md-panel change (20194ba)(\" (bc71d0b), closes #11908ng-model-options (2a01746), closes #104311.8.0Thank you to the contributors who helped with the v1.1.23 release:
\n| ![\"crisbeto\"](\"https://avatars0.githubusercontent.com/u/4450522?v=4&s=117\")
![\"marosoft\"](\"https://avatars0.githubusercontent.com/u/3945455?v=4&s=117\")
![\"nnmrts\"](\"https://avatars0.githubusercontent.com/u/20396367?v=4&s=117\")
![\"Thaina\"](\"https://avatars1.githubusercontent.com/u/1042507?v=4&s=117\")
![\"chmelevskij\"](\"https://avatars1.githubusercontent.com/u/7774918?v=4&s=117\")
This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a patch release that includes bug fixes.
\nmd-select including an a11y overhaulmd-listmd-autocomplete including a regression fix for md-not-found and some usability improvementsmd-select using md-select-header closes on mouse click when not using multiple\n#11969. Will be fixed in 1.1.25.md-not-found template is not styled properly (ce6e2ff), closes #11852md-open-on-focus fails when switching tabs with open datepicker (7a16778)isEventFromControl() works on all browsers now (d537d25), closes #7937z-index not restored on menu close (4a4dde4), closes #11235trackBy, trigger ng-change only when tracked property is different (ecd55d0), closes #11108menuController not defined edge case in focusOptionNode() (b9d8322), closes #11885Thank you to the contributors who helped with the v1.1.22 release:
| ![\"andrewseguin\"](\"https://avatars3.githubusercontent.com/u/22898577?v=4&s=117\")
![\"free-easy\"](\"https://avatars2.githubusercontent.com/u/20483759?v=4&s=117\")
![\"nathanael-bice\"](\"https://avatars2.githubusercontent.com/u/6155868?v=4&s=117\")
| ![\"psamim\"](\"https://avatars3.githubusercontent.com/u/1868679?v=4&s=117\")
![\"qubiack\"](\"https://avatars1.githubusercontent.com/u/19862364?v=4&s=117\")
This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a patch release that includes bug fixes.
\nmd-autocompletearia-activedescendant (#11743) (8c159aa), closes #11742Thank you to the contributors who helped with the v1.1.21 release:
| ![\"neilsh\"](\"https://avatars3.githubusercontent.com/u/49814?v=4&s=117\")
This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a patch release that includes bug fixes.
\ndir=\"rtl\" on any DOM\nelementng-click on md-autocomplete (#11758) (313e5e6), closes #11625aria-expanded (#11740) (197d197), closes #11475navigator is defined before accessing userAgent (#11755) (0077d3e), closes #11751dir=\"rtl\" on DOM elements other than the body (#11579) (bc7833b), closes #11016 #9754document.contains polyfill for IE11 into $mdUtil (#11749) (f5535f8), closes #11745Thank you to the contributors who helped with the v1.1.20 release:
| ![\"Noglen\"](\"https://avatars0.githubusercontent.com/u/38341522?v=4&s=117\")
\n \n\n
Estamos buscando desarrolladores que deseen probar cosas nuevas (con algunas limitaciones) y que deseen\ncompartir tus experiencias con nosotros. Si estás interesado, siga los pasos a\ncontinuación y háganos saber en qué problemas se encuentra.
\n![\"angularCompilerOptions:](\"/angular/angularCompilerOptions-enableIvy.png\")
Esta vista previa se destina principalmente a validar la compatibilidad con versiones\nanteriores, ya que las mejoras de rendimiento y tamaño del paquete aún están en curso.
\nEl plan es asegurarse de que la mayoría de las aplicaciones de Angular sigan\nfuncionando sin cambios significativos, y luego enfocarse en aprovechar las mejoras al\nframework subyacente.
\nHemos logrado un importante hito de estabilidad con la compatibilidad con versiones\nanteriores de Ivy. Basándonos en nuestras pruebas en miles de suites de prueba\ndentro de Google (el 97% de las suites de prueba se pasan en Google), estamos\nrazonablemente seguros de que la mayoría de las aplicaciones funcionarán sin cambios\nen todo el ecosistema. Tenemos varios problemas conocidos en los que estamos\ntrabajando, pero esperamos que haya una larga cola de problemas más pequeños que\nsolucionar.
\nAhora que hemos alcanzado este hito, necesitamos tu ayuda para identificar e\ninformar estos problemas. Inscríbete en la vista previa, pruébelo y háganos saber\nqué se rompe.
\nHay tres cosas que vamos a hacer con los problemas que se nos informan:
\nCorríjalos — siempre que sea posible, queremos utilizar esta entrada para abordar los problemas de compatibilidad con versiones anteriores.
Reconozcalas — algunos de los problemas informados serán de aplicaciones que se basan en comportamientos no especificados o que no forman parte de nuestra API pública. Es probable que no podamos revertir estos cambios, pero queremos entender y ayudar a los desarrolladores a identificar si se están ejecutando en alguno de estos.
Automatizarlos — si hay problemas o patrones a gran escala que descubrimos en todo el ecosistema (como una dependencia o un código problemático escrito por un esquema popular), queremos crear esquemas y reglas de TSLint para automatizar las migraciones.
Todavía estamos trabajando en mejoras para el tamaño del paquete y el rendimiento del\ntiempo de ejecución. Cuando actualice hoy, todavía no verá todos estos beneficios.
\nActualmente estamos viendo que el código generado y las aplicaciones “Hello World” son\nmás pequeñas, pero en algunos casos, Angular en sí es más grande. Estos son algunos de\nlos primeros resultados que hemos visto al actualizar las aplicaciones a Ivy:
\nng new my-app @ 8.1.0-next.1
Antes de Ivy: Paquete principal (135 KiB)
\nCon vista previa de Ivy: Paquete principal (122 KiB)
\nReal World Angular @ 8.1.0-next.1
Antes de Ivy: Paquete principal (358 KiB)
\nCon vista previa de Ivy: Paquete principal (400 KiB)
\nAhora estamos trabajando para reducir el tamaño del framework, de modo que hemos\nreducido el tamaño de los paquetes para aplicaciones reales en casi todos los casos\nantes de que Ivy sea el valor predeterminado. También serán posibles beneficios\nadicionales, ya que ofrecemos nuevas formas de arranque que van a reducir el tamaño\ndel framework en tu paquete principal.
\nHaremos más anuncios sobre el rendimiento y los hitos del tamaño del paquete para\nlas aplicaciones del mundo real en los próximos meses a medida que nos acerquemos a\nactivar a Ivy de forma predeterminada para todas las aplicaciones.
\nTu aplicación debe construir y funcionar como lo hace hoy. Notarás los siguientes\nbeneficios que se deben al nuevo compilador y conjunto de instrucciones:
\nMejoras menores en el tamaño del paquete: ng new es un 10% más pequeño y el código generado debería ver una reducción de ~25% en el tamaño
Mejor rendimiento de compilación: la compilación incremental, la reconstrucción en modo AOT es un 40% más rápida
Mejor rendimiento de las pruebas: en Angular, hemos visto que las pruebas de unidades de framework son 1.5 veces más rápidas, las pruebas de unidades de Angular Material son 2.7 veces más rápidas y el uso de memoria en las pruebas de unidades de Angular Material se ha reducido en un 81%
Instrucciones más depurables — Agregue puntos de interrupción a HTML y pase a través de la representación de la plantilla, y depure más fácilmente la detección de cambios porque puede pasar a la función de plantilla en el traza de la pila y ver dónde se encuentra
También hemos solucionado muchos errores de larga data, hemos mejorado el comportamiento confuso y hemos solucionado algunos problemas de rendimiento.
\nLos enlaces de clase siempre anulan otras clases (7289)
ContentChildren consultas seleccionar nodo de host (10098)
Las consultas tienen un tiempo de resolución inconsistente (21800, 25961)
La bandera de los descendientes funciona inconsistentemente (14769, 27504)
La detección de cambios aún se está ejecutando para los componentes separados que se proyectan (21324)
El comportamiento de referencia de la plantilla local es inconsistente / confuso
Ya no es necesario agregar componentes a la lista de componentes de entrada (28826)
Hemos publicado una guía aquí: angular.io/guide/ivy
\nSiempre debe ejecutar la última versión de Angular desde npm (etiquetada a next) siempre que use Ivy.\nEstaremos haciendo cambios frecuentes en los próximos meses. Puede usar ng update\npara obtener la última versión de la siguiente manera:
ng update —-next @angular/core\nUna vez que estés en la última versión, actualiza tu src/tsconfig.app.json para\nincluir “enableIvy\": true bajo un nivel superior angularCompilerOptions llave.
Cuando ejecutas ng build, haremos la compilación de compatibilidad Angular (ngcc)\nde tu carpeta node_modules/ y actualizaremos todos tus archivos de metadatos en un\nformato que podamos convertir en instrucciones Ivy.
Nos estamos acercando rápidamente a un futuro en el que los beneficios de Ivy son\nautomáticos y universales para todos los desarrolladores y el Proyecto Ivy llega a\nuna conclusión. Mientras tanto,\nabra un problema\no comuníquese con devrel@angular.io para darnos tu\nopinión acerca de tus experiencias con la vista previa.
", "url": "https://devintent.com/blog/2019-06-08-es-hora-de-la-vista-previa-compatibilidad-de-ivy.md", "title": "¡Es hora de la vista previa compatibilidad de Ivy!", "summary": "Detalles sobre la vista previa opcional de Ivy en Angular v8.1.0-next.1.", "date_modified": "2019-06-08T00:00:00.000Z", "tags": [ "angular", "español" ] }, { "id": "blog/2019-06-11-announcing-the-angularjs-material-v1-1-19-release.md", "content_html": "This release is now available in our Online Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN\n(JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a patch release that includes bug fixes, enhancements, and documentation improvements.
\n1.1.18 releasemd-open-on-focus is used (#11719) (73c424d), closes #11701md-prevent-menu-close on checkbox/radio items (#11710) (d577afd), closes #11707Thank you to the contributors who helped with the v1.1.19 release:
| ![\"codymikol\"](\"https://avatars1.githubusercontent.com/u/13606342?v=4&s=117\")
We have released AngularJS Material v1.1.18.
This release is now available in our\nOnline Documentation,\nNPM, and Bower. It is also\navailable on the Google CDN (JS,\nCSS).
\nYou can find the details for all releases in our\nChange Log.
\nThis is a patch release that includes bug fixes, infrastructure, and documentation improvements.
\nmd-svg-icon could cause pages to have multiple SVGs with duplicate id values.Symbol SVG icons are not displayed when using md-svg-icon in 1.1.11+(#11705). This will be fixed in 1.1.19 via PR #11706.
Creating a new tab with pagination enabled does not animate correctly (#11689). This will be fixed in 1.1.19 via PR #11711.
AngularJS 1.7.8 causes an issue with md-select where using requiredwill unset the value of the model. This is being tracked in #11679 and is fixed in 1.1.19 via PR #11724.
.git/ directoryThank you to the contributors who helped with the v1.1.18 release:
![\"AngularJS](\"/angularjs-material/1-1-18-contributors.png\")
We have released AngularJS Material v1.1.17.
This release is now available in our\nOnline Documentation,\nNPM, and Bower. It will be\navailable early next week on the Google CDN (JS,\nCSS).
\nYou can find the details for all releases in our\nChange Log.
\nThis is a patch release that includes bug fixes and documentation improvements.
\nIn 1.1.13, we fixed an issue where the md-autocomplete would sometimes position the options panel on top even when there was no room in the viewport. Unfortunately, this meant that the options panel often defaulted to top position. This was tracked in #11656 and fixed in PR #11670.
The 1.1.14 release was deployed to NPM with a .git directory included in the published package due to a bug in npm publish. This caused NPM to refuse to uninstall or update the package. We’ve fixed this in 1.1.17 and we’re using #11684 to implement a long term fix.
In addition to fixing the two regressions above, this release fixes an a11y regression with md-slider and tab scrolling with wheel devices in Firefox.
1.7.8 causes an issue with md-select where using requiredwill unset the value of the model. This is being tracked in #11679.autocomplete: default dropdown position to the bottom again.
slider: aria attributes are not announced when tabbing in JAWS or VoiceOver. A previous fix for ChromeVox broke this for JAWS and VoiceOver. This new fix has been verified in all 3 of these screen readers.
tabs: use the standard wheel event instead of the non-standardmousewheel event to fix tab scrolling in Firefox.
npm: deploy new release early to fix issue of 1.1.14 including a .git/ dir for NPM installs.
Thank you to the contributors who helped with the v1.1.17 release:
![\"AngularJS](\"/angularjs-material/1-1-17-contributors.png\")
We have released AngularJS Material v1.1.14.
This release is now available in our\nOnline Documentation,\nNPM, and Bower. It is also\navailable on the Google CDN (JS,\nCSS).
\nYou can find the details for all releases in our\nChange Log.
\nThis is a patch release that includes bug fixes and documentation improvements.
\n1 memory leak, 2 regressions, and 5 other bugs fixed
Fixed an accessibility issue with md-nav-bar
Fixed linking to specific sections of the documentation site and specific demos
Build output (JS and CSS files) will be easier to compare from 1.1.14 onward
Somehow this release was deployed to NPM with a .git directory included in the published package. This can cause NPM to refuse to uninstall or update the package. We’re investigating and tracking this in #11684.
AngularJS 1.7.8 causes an issue with md-select where using required will unset the value of the model. This is being tracked in #11679.
In 1.1.13, we fixed an issue where the md-autocomplete would sometimes position the options panel on top even when there was no room in the viewport. Unfortunately, this meant that the options panel often defaulted to top position. We’re tracking this in #11656 and have merged a fix in PR #11670. This will be fixed in 1.1.15. In the meantime, you can use md-dropdown-position=\"bottom\" as a workaround.
\\$mdInteraction: clean up events on $rootScope destroy. This fixes a memory leak when $mdDialog needed to be injected multiple times. This occurred most often in testing, but also effected certain apps that were creating/tearing down the app repeatedly.
icon: large SVG files can cause icon caching to hang. This fixes a regression where sites that use many, rich SVG icons could hang. This is part of an ongoing effort to provide more robust support for SVG icons.
input: placeholder hidden when there is also a label on IE11. This fixes a regression caused by a previous fix for placeholders in md-datepicker on IE and Firefox.
interimElement: don’t track elements that fail compilation. This fixes an issue with $mdDialog, and other interimElements, where an exception during to runtime compilation of the element could cause dialogs to stop responding. This occurred most commonly in apps that used nested or multiple dialogs.
nav-bar: non-selected tabs with anchors have invalid tabindex value. This fixes an accessibility issue where it is not possible to tab out of certain tabs using the keyboard.
panel: caching of panels by id is not working. This fixes an issue where our trackedPanels caching was working for md-tooltip, but not for md-panel.
progress-circular: show correct circle arc when changing from indeterminate to determinate mode. This fixes an issue where changing the md-mode at runtime could cause the arc to be off by about 90 degrees.
virtual-repeat-container: support horizontal scrollbar in vertical orientation. This fixes an issue where a horizontal scrollbar in a vertical list could cover up some of the final items in the list.
docs: properly format anchor names and hrefs. You should now be able to link to a specific demo (I.e. the new Autocomplete Repeat Mode Demo) or documentation section (I.e. AngularJS Material Browser Support). Previously these anchors just took you to the top of the page (prior to 1.1.13) or gave you a 404 (in 1.1.13).
radio-button: correct two misspellings of Latin names in the demo
colors: clean up Closure / JSDoc comments and types
build: make the build output deterministic and reproducible. Previously the ordering of content within our JS and CSS files changed each build. With this change, comparing the build output between releases will be a lot easier.
ci: we moved over to CircleCI from TravisCI in the previous 1.1.13 release
Thank you to the contributors who helped with the v1.1.14 release:
![\"AngularJS](\"/angularjs-material/1-1-14-contributors.png\")
We have released AngularJS Material v1.1.13.
This release is now available in our\nOnline Documentation,\nNPM, and Bower.\nIt is also available on the Google CDN (JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a patch release that includes a couple enhancements in addition to bug fixes and documentation improvements.
\nmd-autocomplete now supports variable-height autocomplete list items when using md-mode=\"standard\". Find out more in the updated docs and the new Repeat Mode demo.
The md-date-filter API will now disable months when looking at the month picker in the md-datepicker and md-calendar. Note that only the first day of the month is checked.
A number of issues specific to IE11 and Firefox were resolved.
md-radio-button styles were updated to better align with the Material Design 2017 spec. This changes the style of focused, unchecked and checked, disabled radio buttons.
The fix for copying links to example/demo anchor headers didn’t quite work as expected in production. It’s been fixed in master via 163b762.
Large SVGs used with md-icon can cause applications to hang since v1.1.11. This is being tracked in #11651 and is being worked on in PR #11653.
We fixed an issue where the md-autocomplete would sometimes position the dropdown on top even when there was no room in the viewport. The improved calculation means that there are more opportunities for the dropdown to show in the default top position where it would have used the bottom position previously. We’re considering changing this to make bottom the first choice again. Please leave us feedback on this in #11656. In the meantime, you can use md-dropdown-position=\"bottom\" as a workaround.
autocomplete: show dropdown on top only when there is room (#11629) (38fb991), closes #10859
autocomplete: suggestions can be highlighted incorrectly (#11529) (320511c), closes #10573
autocomplete: two chips added on enter w/ IE11 (#11528) (705c54e), closes #10640 #10667
checkbox: submit on enter rather than toggle (#11584) (a191a8e) (#11640) (251cfed8), closes #11583 #11639
datepicker: does not open on focus in Firefox (#11521) (45e92ea), closes #10619
datepicker: validation error when adding text after date (#11110) (57c81c8), closes #9994 #10520 #10015
icon: SVG elements are not loaded from the cache properly on IE11 (#11635) (7cde443), closes #11603 #11545#11604
layout: remove some duplicate layout > flex styles (#11613) (6515e6c), closes #11609
list: case where user is unable to interact w/ secondary actions (#11539) (708fff9), closes #9676
menu: fix min-height when scrollable (#11602)
nav-bar: improve focus behavior for click events (#11600) (e64875d), closes #11591 #11494 #11598
radio-group: style focused but unchecked radio buttons (#11564) (8a4105c), closes #11563 #8339 #3643
select: carrot not aligned to end in IE11 (#11544) (bf5bbfc), closes #10714 #3840 #3840
tabs: exception when no selection and header clicked (#11520) (9c079aa), closes #10042
autocomplete: support variable-height autocomplete list items (#11516) (562e0c7)
datepicker, calendar: md-date-filter disables months in month mode (#11526) (8aa5d58), closes #11525
checkbox: clarify description of md-no-ink (#11605)
docs: copying links to example/demo anchor headers gives a bad URL (#11634), closes #11285
menu: add demo and docs for dense menus. (#11602)
ripple: break out docs for $mdInkRippleProvider from $mdInkRipple (#11606)
Thank you to the contributors who helped with the v1.1.13 release:
![\"AngularJS](\"/angularjs-material/1-1-13-contributors.png\")
We have released AngularJS Material v1.1.12.
This release is now available in our\nOnline Documentation,\nNPM, and Bower. It is also\navailable on the Google CDN (JS,\nCSS).
\nYou can find the details for all releases in our Change Log.
\nThis is a patch release that fixes two regressions found in the previous v1.1.11 release.
select: multiple with initial value causes label to overlap with value (#11572) (a4507d6), closes #11571 #11571
tabs: md-center-tabs causes tabs to not render (#11567) (a49043d), closes #11566 #11432
Thank you to the contributors who helped with the v1.1.12 release over the holiday break:
![\"AngularJS](\"/angularjs-material/1-1-12-contributors.png\")
We have released AngularJS Material v1.1.11.
This release is now available in our\nOnline Documentation,\nNPM, and Bower. It is also\navailable on the Google CDN (JS,\nCSS).
\nYou can find the details for all releases in our\nChange Log.
\nv1.1.11 is our largest release of 2018. This release focused on fixing a lot of high priority issues related to accessibility, performance, and cross browser compatibility.
Here are the highlights:
\nOur primary focus this release was on high priority regressions and accessibility issues. We’ll continue with this same focus in v1.1.12.
With the announcement of major changes to Material Design in the 2018 update to the specification, we’ve clarified that AngularJS Material will continue to focus on aligning with the Material Design Spec for 2014–2017. The Angular Material project will be the place to find the latest Material Design 2018+ features.
We reduced the minified CSS bundle size by 76KB as compared to v1.1.10. Also note that this is 93KB smaller than the minified CSS bundle from v1.1.9.
IE11 support was significantly improved with 7 bug fixes. There were also fixes for issues specific to Firefox and Edge.
Tabs received a number of accessibility, cross browser support, and performance fixes. As part of this, there was a regression to md-center-tabs which can cause the tabs to not appear or to appear shifted to the right. This is being addressed and will be fixed in v1.1.12.
Also related to the above change to Tabs, if you use Tabs inside of a non-AngularJS Material dialog, you may see issues with the width of the tab content. You can resolve this by overriding the width of the md-pagination-wrapper. In v1.1.12, you will only need this override if using Tabs with pagination in a non-AngularJS Material dialog.
There also appears to be a regression to md-select when it is used with the multiple option and assigned an initial value. This can cause the label to not float, leaving it overlapping with the values. A fix is being worked on and will be included in v1.1.12.
We hope to have a v1.1.12 release out in mid-January.
autocomplete: screen readers now announce when an item is selected from the dropdown (#11403) (e56424e), closes #10837
autocomplete: apply theme to mdProgressLinear and input (#9698) (affe84b)
autocomplete: ChromeVox indicates selected option on focus (#11441) (ca10bd0), closes #10838 #10970
autocomplete: updateSize incorrectly sets the size to zero (#11500) (d343363), closes #10834
bottom-sheet: theme now supports dark mode (#11380) (4cecebb)
chips: editing chips works again (#11364) (97455f5), closes #11322 #11323
chips: improve screen reader support (#11422) (2268c24), closes #2618
chips: set dirty when a chip is removed (#11363) (0dd688c), closes #11356
datepicker: md-open-on-focus constantly re-opens on close w/ IE11 (#11440) (6596cc7), closes #10999
icon: stop breaking SVG id references when caching icon ids (#11342) (841e8b2), closes #8689
icon: regression causing exceptions to be thrown on IE11 (#11545) (47527f2), closes #11543 #11342 #11162
input: make md-maxlength validation happen on initialization with interpolated value (#11338) (0cb4af1), closes #11329 #11329
input: placeholder and datepicker value displayed overlapping on Firefox (#11538) (44a6946), closes #10440
input: remove placeholder from button accessibility tree (#11404) (2203eec), closes #11293
input: remove unnecessary warnings when ng-messages not provided (#11352) (d48c5b8), closes #10461
input-container: handle initialization of md-icon with ng-if (#11437) (4493389), closes #9529
interim: validate the interim element while closing it (#11509) (6815faf), closes #11507 #10715
list: account for IE11 bug with Flexbox and min-height (#11393) (e3c1a5c)
nav-bar: improve screen reader support (#11486) (6b29548), closes #11485 #11485
nav-bar: set ng-href on nav-item even if md-nav-href is empty (#11488) (e876eec), closes #11487
nav-bar: update keyboard navigation to WAI-ARIA guidelines (#11494) (4d29450), closes #10419 #11489
select: display asterisk on label only if empty (#11355) (f7b7f10), closes #11312
select: give focus to the first option when loaded asynchronously (#11372) (998199f), closes #11357
select: perform full cleanup of the select drop-down after the close (#11448) (dfba062), closes #11447
select: theming issues with md-select-value (#11373) (9852ff7), closes #9592
select: extra scrollbar when select dropdown is open (#11453) (20fc2d8)
select(multiple): Remove side-effects to forms when adding md-select elements (#11491) (97e2d00), closes #11490
sidenav: refactor syntax to work around issue in babel-minify (#11351) (0ed110b)
switch: theming issues with focus in dark theme (#11459) (71e0411), closes #8518 #11417
tabs: provide guidance on how to navigate between tabs (#11402) (4b1b729), closes #10895
tabs: show a visual indication of tab focus (#11392) (1d73d81)
tabs: tab labels overly truncated on IE11 when pagination active (#11432) (2b2f441), closes #10406
theme: prepend # to hex codes for enableBrowserColor (#11492) (0306ac0), closes #11259
toast: improve a11y support for $mdToast.simple(). improve docs (#11424) (fedb9a3), closes #349
toast: remove the interim element from the list before closing element (#11427) (f616b25)
autocomplete: add input-aria-label and input-aria-labelledby (#11412) (534beea), closes #10815
autocomplete: add support for input-aria-describedby (#11405) (a25a7df), closes #11004
contactChips: add basic support for md-separator-keys (#8142) (eb10b56)
slider: enable page up/down and home/end keyboard actions (#11517) (70654c3), closes #11515
tabs: allow specifying custom class names for tabs (#11332) (aa30ada)
theming: add ability to specify hues as options to defineTheme (#11428) (f776bf7)
tabs: md-center-tabs causes in high CPU usage (#11375) (7fdf9da), closes #9690 #6375
tabs: remove unreferenced elements variable from TabsController (#11379) (33652b4), closes #11377
css: remove bloat from auto prefixing of unsupported browsers (#11340) (3660a32)
This auto prefixing change reduced the minified CSS bundle size by 76 KB. You can find the breakdown of supported browsers here.
\nWe’ve updated our home page to include more details about the browsers and versions that AngularJS Material supports.
We made many small tweaks to the docs to fix broken links, update URLs to the Material Design 2014–2017 Spec, and fix syntax and formatting.
We also made changes across the docs and demos to properly support dark mode themes.
a11y: audit of our entire docs and demos site to resolve most all of our accessibility issues identified by Lighthouse
icon: update our guidance for using SVGs and provided details about the new Material Design Icons tool
contact-chips: add docs for md-highlight-flags
highlight-text: add md-highlight-flags example
list: clarify the docs around md-avatar-icon
slider: add missing docs for APIs like md-vertical. Fix demos in IE11
input: fix issues with displaying the types in the docs. Add docs for md-select inside of md-input-container
select: add missing docs for md-option and md-optgroup
toast: add example of using locals to the custom toast demo
typography: fix URL for Roboto font and general cleanup of the guide
Thank you to the contributors,\nespecially the first timers, who helped with the v1.1.11 release:
\n![\"AngularJS](\"/angularjs-material/1-1-11-contributors.png\")
After exploring the\nPixelbook as a development platform,\nI decided that I need to replace my mid-2014 MBP w/ 16 GB RAM 256 GB SSD and Intel graphics with the new\n2018 MBP w/ Touch Bar 32 GB RAM 512 GB SSD and Vega 20 graphics.
\nI am going to use this post to chronicle the first days of using this machine. I hope that it will help other\ndevelopers and professionals who may also be looking at the latest MacBook Pro line up. Oh and I’m sure\nthere will be some gaming content in here as well 😁
\nWhen I purchased my 2014 MBP, I opted to pass on the Nvidia discrete graphics card. This was based on two\nprimary drivers: heat and usage.
\nAt the time, I had a Dell XPS desktop for gaming. So I didn’t intend to do any graphics heavy tasks on the\nMBP. I was also upgrading from a Chromebook Pixel 2013 which had a very hot i5 CPU. Thus, I wanted to get a\ndevice that I could use on my lap while doing basic web browsing or writing.
\nFast forward to 2018, my 2014 MBP is 4.5 years old and well outside of the extended warranty plus my gaming\ndesktop is about to be retired. I’m also in a situation where I anticipate needing to be able to do all of my\nprofessional work on a mobile platform for the next few years. This means that something like the attractive\n2018 Mac mini won’t work for me.
\nI watched the early 2018 MBP i9 thermal drama unfold from a distance. I was happy to see that Apple quickly\nreleased a patch for this. The resulting benchmarks were acceptable to me. Additionally, as a developer, the\nburst speed of the i9 processor is valuable to me as it helps to eliminate micro interruptions in my workflow.\nI don’t really need to run the CPU at max for extended periods of time as is needed for video processing.
\nI was convinced to go with the Vega 20 after watching a number of videos that covered the benchmarks,\nthermals, and real world performance. For reference, some of those include:
\nIs Vega 20 Worth it for 15\" MacBook Pro? Benchmarks & Thermals
Vega 20 MacBook Pro Gaming — Battlefield 5, Black OPS 4, and Fortnite!
A brief summary of those videos
\nThe thermals of the i9 w/ Vega 20 seem to be improved over those of the i9 w/ 560X even in pure CPU tasks.
The Vega 20 was able to get 60+ FPS in modern games at medium settings and in slightly older games at high settings.
The previous issues of throttling and stuttering during game play have been resolved (I believe as part of the thermal patch).
The i9 w/ Vega 20 graphics provided a ~20–60+% increase to graphics performance for ~10% increase in cost.
Gaming on Windows 10 in Boot Camp provided an increase of about 10–25 FPS over the same in macOS.
Additionally, I researched peripherals and adapters so that I could work with USB-C effectively. I\npicked up a USB-C card reader and\ntwo Thunderbolt 3 to HDMI adapters. These were used to\nhook up my two external monitors and, since the MBP has 4 USB-C ports, I’ll also be able to\nplug in power and a dongle for my external mouse and keyboard. The adapters also came with a discount for a\nThunderbolt 3 to VGA adapter which will be useful when\npresenting at some schools and meetups. I decided to wait on ordering a dock until I was confident the\nlaptop was going to be a keeper. The dock that I have my eye on is the\nCalDigit Thunderbolt 3 dock w/ 85 W charging.
\nMy new MBP shipped straight from Shanghai. There was a delay of 2 days in Japan and that triggered UPS to\npush my expected delivery date by 4 days. Thankfully, soon after that it started moving again and was quickly\nback on track for on time delivery.
\nWhen FedEx delivered my new MBP, it was a familiar unboxing experience. I went with silver, partially since\nI didn’t want a darker color that might absorb more external heat. It’s probably only the smallest possible\ndifference, but it was enough for me 😉
\nThe feel and build was similar to by 2014 MBP, but there were some differences. It felt slightly thinner\noverall and instead of a light up apple on the top, it’s just a shiny silver apple. 👍🏼
\nWhen I opened it up, the giant touchpad really stood out and worried me that it might cause issues\nwhile typing. The Touch Bar was there too… and the keyboard…
\nThankfully it arrived with macOS Mojave already installed.
\nI booted it up and wasn’t sure what to expect of the Migration Assistant. The first attempt was with Wi-Fi,\nbut I saw a message that connecting to my old MBP via USB would be faster. So I got the USB-A to USB-C data\ncable that came with my Pixel XL and plugged that in to each laptop. My old MBP detected it and switched to\nPeer-to-Peer networking, but the new MBP got stuck at “Switching”.
\nI had to cancel and restart the process. This time connected via USB from the start. I also had to make sure\nto overwrite and not duplicate any of the users, or the files (uncheck a box in the Migration Assistant wizard).\nThe migration went smoothly this time. It originally estimated around 3 hours and 45 minutes to complete, but\nit was done within a couple of hours.
\nI knew that it was going to try to migrate some apps and settings, but I didn’t have high hopes and expected\nto install a bunch of apps and tweak a lot of settings after it was done. To my surprise, it basically copied\nover my entire device to the new device with almost nothing missing other than re-granting security and\naccessibility permissions! This was really the experience that I was hoping for!
\nThis gives me a lot of confidence that should I have a MBP fail, I can restore to another MBP device from a\nTime Machine backup and be productive again in just a couple of hours. This is critical to me and my\nconsulting business.
\nI read a number of articles about installing Windows 10 via Boot Camp and it seemed somewhat straight forward.\nIt was my first time working with Boot Camp though.
\nI downloaded the 5.08 GB Windows ISO from October 2018. I picked 150 GB for my Windows 10 partition and started\nit up. After about 30 minutes, it failed to copy the Windows files and started trying to back out the\npartitions that it had created. This seemed to get stuck, so I had to cancel it and manually clean up the\npartitions as detailed here.
\nThat same article explained\nthat the issue was Boot Camp’s partitions being FAT32 which support file sizes up to 4 GB. Then it provided a\nBoot Camp ISO Converter tool to split the ISO into smaller chunks in Boot Camp. I also disabled Time Machine\nand installed an update to Mojave just to be safe. This worked like a charm for me!
\nWindows 10 on a Mac was quite disorientating to me initially. Dragging windows with the touchpad didn’t seem\nto work and tap to click wasn’t enabled. Thankfully I found options in the Boot Camp settings to enable tap\nto click. It also had an option to change how window dragging worked, but that didn’t seem to help. I just\nhad to figure out that I had to click and drag all with one finger instead of holding a click with one\nfinger and dragging with another finger.
\nThere were some prompts to install drivers, Windows updates that needed to install, virus scanning, and the\nusual range of other Windows tasks that had to be sorted out. I also went and cleaned up most of the privacy\nsettings, disabled Cortana, and uninstalled as many Windows store apps as possible. Oh but I did install\nSlack from the Windows store. Then I downloaded and installed Chrome, Firefox, NVDA, Guild Wars 2, and\nStar Wars, The Old Republic.
\nDownloading, installing, and patching these games really gave the machine a workout. It flew through most\ntasks, but this got the fans going and got the CPU load up to around 18% while the Wi-Fi was going as fast as\npossible (unfortunately, we don’t have Fiber here). Even with all of this load, the palm rest remained a\ncomfortable ~45C while the CPU ramped up to around ~80C. It certainly created a hot spot on my desk and\nwould not have been comfortable on my lap under this kind of load.
\nThat said, while sitting here in macOS with a 30+ open Chrome tabs, Slack open, numerous menu add-ons\nrunning, lots of Chrome extensions enabled, and writing this post, the palm rest is at a cool 30C, the GPU\nis only 35–40C, and the CPU is 38–45C. These temperatures are perfectly comfortable to use on your lap.
\nThe MBP handled this load just fine over a period of about 3–4 hours while ~80GBs of game assets and patches\nwere downloaded. After one of the games finished, and the other was playable, but downloading background\nupdates, I decided to walk away for a bit and shut the lid. Doh! I hadn’t changed the Windows 10 settings\nfor this, and it went to sleep right away. I could tell when the fans cut off about 20 seconds after closing\nthe lid.
\nI opened it back up and went to change the setting when BSOD! Windows crashed, and the Event Viewer\ndidn’t have much useful information for me. I didn’t see anything related to bridges or T2 chips… After\nrebooting, I was able to change the setting and get it to keep running after closing the lid.
\nAbout 5 hours later, after all the updates and downloads finished, I was installing NVDA when\nWindows 10 prompted me with a popup about sound issues. Then another BSOD! After rebooting, I was\nable to install NVDA without any problems. I tested using it for a bit and verified that sound was\nworking in Google Play Music.
\nUsing a Nonda USB-A to USB-C adapter,\nI was able to work with my U2F security key just fine. This adapter is Thunderbolt 3 compatible and passes\ndata just fine while I have another adapter that only handles charging and doesn’t work with data. Keep\nthis in mind if you are looking into USB-C adapters. I had picked up this attractive Nonda adapter at\nDevFest Florida 2016 as a speaker’s gift.
\nI decided to head back to macOS in order to write up the first day of experiences and to start testing\nperipherals like my external keyboard, mouse, monitors, and backup drive.
\nNow I’ve been typing on this keyboard for a few hours now… It’s certainly worse than my 2014 MBP, and\nit’s much worse than the Pixelbook’s keyboard. Even with the minimal typing required for installing\nsoftware and entering basic details, it caused me to make a lot more mistakes than usual. I figured that\nthis might just take some getting used to, so I waited until day 2, after writing this post, to provide\nfeedback on the typing.
\nSo the verdict after writing up this post with the MBP 2018 keyboard? I can certainly still type fast!\nBut there are a lot missed keystrokes and mistyped keys, much more than any other typing experience that\nI’ve had in years. The “new, softer sounding keys” are too loud for my tastes and the “new, softer feel”\nis also not something that I am happy with.
\nThe arrangement of the up and down arrow keys on the MBP is not something that I like compared to the 2014\nmodel. That said, it hasn’t caused me too much pain, yet.
\nI don’t know if there is a setting for this or not, but the caps lock key’s light only seems to work about\n20% of the time. I don’t know how, why, or when it decides to work, but I’ve seen it come on. If I click\nit a bunch of times here in Medium, the light stays off, but the caps lock mode does enable and disable.\nSolved: this turned out to be a bug in Karabiner\nthat was fixed in their beta a couple months ago and just got fixed in their stable release in February 2019.
In my home office, these keyboard issues won’t be a problem since I’ll be using a trackball and external\nkeyboard. However, I’ve never been a person to carry an external keyboard to co-working spaces. That may\nneed to change. I wonder if there is already a keyboard on Kickstarter that fits over the top of the\nMBP’s keyboard 🤔
\nNow before we get into the Touch Bar, I just wanted to be clear, the MBP 2018 keyboard is by far the\nmost underwhelming and disappointing feature of the device.
\nI am generally happy with the touchpad so far. I’m also happy with the Touch ID sensor. However, I wish that\nI could use my fingerprint for even more of the admin password prompts.
\nThe Touch Bar experience in Windows 10 was a little confusing. Sometimes the volume up and down virtual\nkeys would work, sometimes they would not. The esc key seemed to work.
The Touch Bar experience is unsurprisingly better in macOS. I have enjoyed being able to tap the volume or\nbrightness buttons and then use the slider to find a setting that I was happy with. Some shortcuts\nin Finder and Chrome are useful, but I haven’t used them much yet.
\nSlack doesn’t offer anything but the default esc and brightness / volume / mute / Siri virtual buttons.
The Touch Bar in JetBrains’ WebStorm and IntelliJ IDEA seems quite useful! Here’s what I see when I open a project:
\n![\"Touch](\"/large-images/touch-bar-webstorm.jpeg\")
You can see that it offers me a menu to pick from the Run Configurations, then buttons to run, debug, or\nstop a Configuration. Additionally, it offers to the Git Update and Git Commit buttons.
\nIf you open the Run Configurations menu, you can scroll through the options in the Touch Bar:
\n![\"Scrolling](\"/large-images/touch-bar-run-configs.jpeg\")
In this case, there is a green dot on “Watch Site” because it is currently running. If I exit the menu,\nI can see that the Run button has changed to Re-run, and the Stop button is enabled:
\n![\"Run](\"/large-images/touch-bar-re-run-stop.jpeg\")
Even the Git Commit dialog has Touch Bar support. In this case it saves me an extra click by showing\n“Commit and Push…” in the Touch Bar:
\n![\"Picture](\"/large-images/touch-bar-commit-and-push.jpeg\")
Since I use a Logitech K800 Wireless, back-lit keyboard with a Windows layout for most of my work, I have\nthe F1-FX keys mapped to actions like volume up/down, mute, etc. Thus, I don’t really make use of these\nFunction keys when doing development. My primary shortcuts in WebStorm are all configured to use\ncontrol , shift , option , combinations instead.
That means that I’m not really sad to be “missing” the F keys. I also haven’t hit a situation yet where\nI needed the esc key, and it wasn’t there. I’ll certainly be keeping my eye open for that though.
Verdict after 2 days: I’m learning to live happily with the new Touch Bar. Hopefully I don’t like it too\nmuch though. There are no external keyboards with Touch Bars yet and getting used to this 2018 MBP\nkeyboard isn’t proving to be easy.
\nEverything went super smoothly with hooking up two 27\" AOC 1080p HDMI monitors, an Anker 10 port\nUSB 3.x Hub, and power. The time it takes to wake and sync the monitors seems to be cut in half\ncompared to my 2014 MBP w/ Intel graphics.
\nI was a little worried that, with all 4 USB-C ports in use, I would have a problem with using my\nTitan U2F Security key. That was solved easily by just plugging it into my Anker Hub.
\nI haven’t had time, or a need to test out my Uni Thunderbolt 3 to VGA Adapter or\nAnker Thunderbolt 3 SD Card Reader yet.
\nIt’s certainly a pleasure to be using this high speed laptop with my beloved Logitech K800 keyboard and\nM570 Trackball!
\nI noticed that Logitech released the new MX Ergo Trackball\nlast year. So I put in an order immediately since it was at its lowest price in 4+ months (it’s now about \\$6\nhigher than yesterday). I can’t wait to try it out after 5 solid years with two of the M570s.
\nI also did a lot of research on keyboards in the last 2 weeks. I got some great recommendations for things\nlike the Code keyboard, and the Apple Magic keyboard, however I’m looking for a wireless, back-lit keyboard\nwith a Mac keyboard layout. The Code isn’t wireless. The Magic isn’t back-lit. The K800 has a Windows layout.
\nI looked at the Macally keyboards, but wasn’t able to find a good fit. However, it sounds like they may be\nlaunching something that meets my needs in the next few months.
\nI got a suggestion for Matias keyboards as well, but there are too many reviews that are very negative on\nthe typing experience.
\nThe best match that I can find seems to be the new Logitech Craft keyboard.\nHowever, it’s $199 MSRP (twice that of the K800) stopped me in my tracks. It’s currently $169 on Amazon, but\nI’m going to try waiting a few more months to see if there are any price dips. One of the biggest complaints\nwith the Craft is the Logitech software support. Hopefully over the next few months, they can squash a few\nmore bugs.
\nI spent a good deal of time cleaning up my machine today. This meant removing old VirtualBox VMs and\nuninstalling VirtualBox since I have VMWare Fusion now. While doing that I noticed some old multi-GB\ndocker images, Android Virtual Devices, and some other cached files from NVM, Gradle, Maven, etc that\ncould be cleaned up.
\nI also noticed that some programs weren’t compatible with Mojave. This wasn’t an issue with the new MBP,\nas the same needed to be done on my old laptop as well. This just meant downloading and installing updates\nto things like KeyCastr, Robo 3T, Android File Transfer, Postman, Logitech Camera Settings, Logitech\nControl Center, etc.
\nWhile Git, SSH, GPG, and many other CLI tools were working fine after the migration, there were still\nsome issues with MacPorts giving some plist warnings when running sudo port selfupdate. I followed\nthe steps in the Install Guide and I was back up and running\n(without needing to do the steps in the Migration Guide).
I also spent some time customizing the key mappings when using my external keyboard via\nKarabiner Elements. While doing this, I noticed that my volume up,\nvolume down, and mute keyboard buttons were working w/o the need to map them to a Function key.\nSome time ago, this wasn’t working on my 2014 MBP, but I didn’t go back to verify if this still an\nissue on that device.
\nJust like I saw with the built-in keyboard, the caps lock light not coming on while using my\nLogitech K800. I tried to enable Karabiner’s option to “manipulate” the Caps Lock LED, but it didn’t help.\n**Solved: **this turned out to be a bug in Karabiner\nthat was fixed in their beta a couple months ago and just got fixed in their stable release in February 2019.
I ran into some confusing behavior in Chrome that seems to be related to the Migration. I went into Sharing\nSettings to give this new Mac an updated Name. This didn’t seem to help though. Whenever I go into Chrome’s\nHistory and look at “tabs from other devices”, I can’t see tabs from my 2014 MBP. It’s like Chrome somehow\nthinks that the two devices are a single device. I disabled and re-enabled sync on both devices without any\nluck. I stopped short of completely clearing my sync data, which the forums mentioned may be required.
\nI also setup Chrome Remote Desktop. After the migration, this meant disabling remote desktop on both MBPs\nand then re-enabling it with updated names and PINs.
\nOverall, things are feeling clean and fast now. This “Spring cleaning” cleared up around 20 GB of disk space.
\nI also watched a nice summary video on this machine from AppleInsider
\n\nIt looks like some of my keyboard settings didn’t make the migration. I noticed that I wasn’t able to hold\na key to have it repeat. This is especially important with delete. I found that the “Delay Until Repeat”\nsetting in Keyboard settings was set too long. I moved it to the second shortest value. Then delete\nstarted working as expected. So of course I tried it with some other keys like aaaaaa, but that didn’t\nwork! Instead, it opened up an accent picker.
This was new to me. An AppleInisider article\nhelped me understand what was going on. I am happy with the option shortcut method:
![\"Keyboard](\"/large-images/keyboard-viewer-option-key-pressed.png\")
This screenshot is showing that if you want to type ü then you need to press option+u and then u again.\nUsing this same approach but typing option+u and then e will give you ë. Great! This will work\nperfectly for me when I need to use different accents (something that I am trying to get better with in\nSpanish).
However, I want to repeat keys on long press. To do that, I found\nthis answer which advised running the following in the\nTerminal to disable the accent picker on long press:
\ndefaults write -g ApplePressAndHoldEnabled -bool false\nThen you need to reboot for it to take effect.
\nI went back to work with a full focus on productivity. This machine blew my mind with its speed 🚀 and\ngeneral productivity boosts ❤️. I haven’t taken measurements yet (planning on it), but there is a very\nnoticeable improvement in the speed in my every day development and testing tasks.
\nI decided to dig into the media aspect of this device. I used an Anker USB-C SD Card Reader to pull 25 GB of\nphotos off of my DSLR. Then I proceeded to copy and organize those files before batching uploads to both\nGoogle Photos and a Synology NAS. This resulted in driving the network card and CPU quite heavily for many\nhours in a row. Everything went extremely smoothly.
\nI’m not an experienced video editor, but I did some work on some small video editing in iMovie. I’ve\nidentified a 2.75 GB video that I plan to do some additional testing with. Other than my own issues\nlearning to use the iMovie user interface, everything here went smoothly as well.
\nThe Logitech MX Ergo Trackball arrived. Pairing it up with the Logitech receiver and installing Logitech\nOptions was simple. The transition from the Logitech M570 Trackball was pretty smooth. After a few hours,\nmost all the minor differences faded away. This even included using the Ergo at the 20 degree tilt.\nI appreciate the minor amount of extra friction / stepping in both the trackball, and the mouse wheel.\nThe precision mode is very handy, but I forgot to use it earlier when I was editing images in GIMP.
", "url": "https://devintent.com/blog/2018-12-07-my-experience-with-the-macbook-pro-2018-w-vega-graphics.md", "title": "My Experience with the MacBook Pro 2018 w/ Vega graphics", "summary": "Description of migrating to and configuring a new MacBook Pro 2018 w/ Vega graphics from a web developer.", "date_modified": "2018-12-07T00:00:00.000Z", "tags": [ "mac", "webstorm", "chrome", "git" ] }, { "id": "blog/2018-11-25-my-pixelbook-dev-experience.md", "content_html": "I ordered the i7 16GB RAM 512GB SSD Pixelbook with the Black Friday deal that started on\nNovember 22nd.
My Pixelbook arrived this afternoon. Within a few hours, I’ve already got my\nprimary dev tooling installed and working!\nThere were only a few minor bumps in the road, and they were quickly resolved with a quick Google search.
\nI’m curious how things will play out over the next week as I try to push it for productivity tasks.
\nI’ll also be monitoring the thermal performance since I don’t want to be working at some point in\nthe future with burning finger tips. So far today, I felt some heat when I reached up above the\nkeyboard and below the screen. However, when I checked\nCog,\nthe temps were actually not bad at all (160 F / 71 C or less).
\nWith the machine mostly idle, 4–5 tabs open, while I wrap up this post, the CPU is barely over body\ntemperature at 104–109 F.
\n![\"Screenshot](\"/large-images/pixelbook-cog-monitoring.png\"){kind=tracking}
The battery life is very impressive so far. I’ve been off of power most all day, and I’ve still got\nover 30% power remaining and almost 3 hours of estimated run time.
\nI’ll also be doing a good deal of testing with Bluetooth. I was able to use an LG Tone 700 headset\nfor over an hour today without any disconnections or issues.
\nThere has been one minor usability glitch that has bothered me a few times today. On about 5–10\ndifferent occasions, the machine seemed to lag or freeze up. Sometimes this was only affecting the\nscroll of the touch pad, or the responsiveness of the touch screen. Other times the entire UI was\nfrozen and there was no way to interact with the device. This generally only lasted 1–20 seconds…\nuntil just about 5 minutes ago.
\nI wrote 99% of this post on the Pixelbook, but I’m finishing up the first draft here on my mid-2014\nMacBook Pro. With 30% battery left and low heat (as seen above), I closed all of my Linux and\nAndroid apps. I also closed a few open tabs to get down to only 4 tabs open. Then while making\nminor edits to this post in the Medium web app, everything froze.
\nIt never came back. After about 5 minutes, the machine rebooted itself to this:
\n![\"Picture](\"/large-images/chrome-os-damaged.jpg\")
I pressed the power button and tried to reboot it, but it just turned off. There were no connected\ndevices. Nothing I did was able to wake it back up, even holding the power button for 30+ seconds,\nuntil I plugged it into power. It then booted up pretty quickly and still had 29% battery left.
\nThat was… a little scary. When I first unboxed the device, I had a similar experience. I couldn’t\nget the power button to do anything. Only when I connected my Pixel XL via USB-C did it power on\nand start responding.
\nI found out that the Chrome OS missing or damaged screen\nisn’t new and isn’t that uncommon.
\nI didn’t have a lot of time today for development tasks, but I did get a good deal of web browsing,\nand a little Android gaming done. I found that using the device on the lap in either tablet or\nlaptop mode did not generate enough heat to bother me. This was after about an hour of web browsing\nand some Star Wars Galaxy of Heroes.
\nOn the gaming side, I’m still getting a feel for the touch screen as there are quite a few occasions\nwhere I don’t touch it with enough force to register and need to tap again. Gaming performance-wise,\nI’m seeing a significant improvement over my Nexus 9, but I feel like my Pixel XL may outperform the\nPixelbook in the GPU category.
\nI was able to get the Google Cloud SDK (gcloud) installed using their\ninstructions for Debian.
\nI was able to get IntelliJ IDEA installed and running with almost the same instructions that I used\nfor WebStorm. I ran into an issue with the Google Cloud Tools plugin and\nopened a bug.
\nI was also able to get Android Studio installed and running. I am generally able to install the\nSDKs and libraries and get my Gradle builds to succeed. However, there are a number of other minor\nissues like not being able to sign in to Google due to the callback going over a port that isn’t\nforwarded to Crostini and resolution of secondary SSH keys when using Git. Android Studio suggested\nthat I install libsecret-1-0 and gnome-keyring so that it could preserve access to my keys, but\nit doesn’t appear to be working.
I’m also seeing an issue where I need to re-authenticate with GitHub either after rebooting or\nre-launching of WebStorm. It says “missing access token” as if the previous token has been lost. I’m\nseeing similar issues using a secondary SSH key in WebStorm as well.
\nI’m getting the feeling Crostini and Chrome OS are on the edge of being a real development platform.\nHowever, the concern that Crostini (beta) may have too many productivity-draining issues with edge\ncases is getting more real.
\nI spent many more hours trying to get a second SSH key to work in IntelliJ IDEA and WebStorm. I\ntried both the Built-In and Native SSH, but had no luck. Then I learned about, and setup, a\nssh-agent service with systemctl.\nAdditionally, I tried keychain and gnome-keyringsome more. Even though everything appeared to be\nset up properly and worked from the Terminal, it would never work from the IDE.
I finally just gave up and decided to use the key for associated with my BitBucket account for\naccessing both GitHub and BitBucket. I was able to add that email address to my GitHub account.\nI’ll have to wait and see if this causes me problems with some PR review bots, commit\nverification, or CLA checks in GitHub.
\nI found out today the issue I reported about the Google Cloud Tools plugin for IntelliJ IDEA wasn’t\nspecific to Chrome OS. It was just an issue that they hadn’t added support for the latest version of\nIntelliJ (2018.3). They released that fix today, and it resolved the issue.
\nI did however run into another problem with that plugin. It uses a strategy where it logs you in\nvia OAuth redirects. However, when it tries to send the confirmation back to the IDE, the browser\nshows a Not Found page. This is because they use a random high level port (40–60K) each time, and\nthose ports are not forwarded between Crostini and Chrome OS. Only some well-known ports\nare forwarded. For now, being logged into the Google Cloud Tools plugin is not critical for my work,\nso I am going to ignore this issue.
\nThat said, Firebase is critical for my work, and they use a similar model for authenticating with\ntheir firebase-tools CLI. I’ll have to give that a shot soon to see if it will be a problem.
Another important activity that I did today was hosting a two-hour Hangouts Meet video call. I did\nthe whole call connected to my LG HBS 700 Bluetooth headset without any issues. I did some screen\nsharing and navigated through a few tabs while on the call. Everything was smooth for about 99% of\nthe call. I didn’t notice any excess heat being generated and the keyboard and palm rests were still\ncomfortable to use.
\nThe other person on the call was also using a Pixelbook. While the video quality on both sides was\nacceptable, I wasn’t really impressed. The Pixelbook has a 720p 60 FPS webcam which should be\nsimilar in quality to my MacBook Pro mid-2014’s 720p webcam. However, in this small sample, I felt\nthat it wasn’t really up to par with my MacBook Pro. There was a bit of graininess and as it got\ndark, the low light performance didn’t seem to be very good.
\nNote that this is just anecdotal evidence based on a general feel and not head-to-head comparison.
\nI also have some feedback on the keyboard, palm rests, and track pad. In general, the keys have a\nreally nice feel and are a pleasure to press. I do still get a little disoriented at times and end\nup pressing keys 1 column to the right, but I don’t see that being a long term issue.
\nI VERY frequently press the Assistant key when I do not desire to speak with the Assistant. I\nreally wish that it was up near the function keys, perhaps replacing the hamburger/settings key.\nHowever, I haven’t taken the step to disable it yet, but it’s certainly under consideration.
\nThe palm rests are excellent! They are very comfortable and keep quite cool! Similarly, the track\npad is really a pleasure to use! Sometimes Chrome OS doesn’t scroll quite as smoothly or\nresponsively as I would like, but that isn’t an issue with the track pad itself.
\nI did some interesting reading today over at the\nCrostini Wiki and\nSimos Xenitellis’ Blog.\nThe wiki has some great resources and guides for installing and configuring different tools. The\nblog post covers some internals of how Crostini is built.
\nOh! Finally, I learned\nhow to insert emojis 🌟!\nThis is also helpful for adding in some special characters like jalepeño. Unfortunately, the\nemoji picker doesn’t have text search (like macOS or Slack) 😞 and there are no tooltips on hover\nto help you differentiate similar emojis. Additionally, there appears to be a bug where I’m not\nable to use the trackpad to scroll through all the emojis (the touch screen does allow you to\ndo this though).
\nWhile I have not run into Bluetooth issues with my Pixelbook, there are a lot of other reports out\nthere. It looks like a firmware fix from Intel will help mitigate some of these issues in\nChrome 71 (beta). Stay up to date by starring this\nbug.
\nI’m finally running into random Bluetooth disconnections. I had 3 of these today in about 30 minutes\nof SWGOH with my LG HBS 700 connected. One note on the positive side, this is certainly the best\nsound I’ve ever had on SWGOH. On some Android devices (like the Nexus 9), I can sometimes get poor,\ncrackling audio. On the Pixelbook, it was so crisp and deep! I heard sounds that I had never been\nable to discern before!
\nIt looks like there is some bad news for Pixelbook Bluetooth users in the above bug. Today, the\nChromium team responded that while things have been improved with the firmware update in Chrome 71,\nthere is still an underlying hardware issue that won’t be able to be resolved in existing hardware\n(Pixelbooks included).
\nIf you need a device with solid Bluetooth performance, it doesn’t look like the Pixelbook will work\nout for you. The bug mentions that the Pixel Slate and\n‘Nami’ devices, including\nthe Acer Chromebook 13 and Spin 13, should have the hardware capability to have Bluetooth that\nauto-recovers (without a reboot) when it has issues.
\nI spent a couple of hours coding while streaming Google Play Music over Bluetooth via the web\n(not the Android app). I wanted to try this to see if my earlier disconnects were related to\nactively using an Android app. It wasn’t related. I had about 6 more disconnects (with no auto\nreconnection) over this time. Again, the sound seemed very clear, but the disconnections make it\nproblematic to use the Pixelbook with any Bluetooth accessories 😞
\nToday I decided that it was time to try the Beta Channel of Chrome OS. The main reason was to try\nout the Intel firmware update for the Bluetooth/Wi-Fi chip. It took about 15 minutes to download,\ninstall the updates, and reboot.
\nThis evening I streamed music while coding for about 5 hours with numerous breaks, disconnections\ndue to going out of range, turning my headset on/off, etc. I also got in about 30 minutes of SWGOH\nwith BT. Thankfully, I can report that I did not have a single bogus disconnection, and the system’s\nBT did not disable itself.
\nI didn’t do any coding or fiddling with configuration today. I needed to get my productivity up, so\nI stuck with my MacBook Pro for dev today.
\nI was busy working on my MacBook Pro for most of the day, but I streamed Google Play music for at least 3–4\nhours on BT without any disconnections or issues.
\nI also ordered a set of USB-C to HDMI adapters so that I could do some testing with dual external\nmonitors. I didn’t want to spend the money on a whole\nUSB-C Hub with video out yet.
\nI hooked up the following today
\nUni USB-C to HDMI adapter to AOC 27\" monitor
Anker 10 port USB-A 3.0 Hub
Logitech K800 Wireless Keyboard
Logitech M570 Trackball
Western Digital 1 TB My Book for Mac
In this configuration, I was only using one of two monitors, but this allowed me to have WebStorm\nrunning side by side: macOS vs. Chrome OS.
\nI messed with the scaling in the Chrome OS display settings a bit. However, with this configuration,\nanything but 100% scaling resulted in blurry text in WebStorm. I needed to bump my font size in\nWebStorm up from 9 to 12 (same as in macOS). I had previously lowered it for the Pixelbook display.\nLater when I opened WebStorm settings, it appears that the font size was auto converted to 28.
\nI also had to tweak the font since the Menlo font that I use on macOS isn’t available on Chrome OS.\nI settled with Fira Code Medium.
\nWith the scaling and font sizes sorted out and both displays of WebStorm (macOs, Chrome OS) looking\nsimilar, here’s what I noted
\nThe text in the Project panel (where your files and directories are) has a real nice contrast in\nmacOS, but it’s smaller and dull in Chrome OS.
Many parts of WebStorm on Chrome OS are smaller and need to be scaled up to match the size on\nmacOS. Unfortunately, I can’t do that due to the blurring.
Fonts and UI elements are significantly sharper on macOS. This actually used to be a weakness\nwhen running any IntelliJ product on macOS compared to Windows. However, JetBrains solved this issue\na couple of years ago. It looks like some kind of similar fix is needed for Chrome OS’ Freon\ngraphics stack.
After this, I decided that I needed to get two external monitors set up. However, this meant losing\nmy external mouse and keyboard since I don’t have a USB-C Hub. The good news is that the Pixelbook’s\nkeyboard and trackpad are excellent, so I’m using them in that configuration to write up this post.\nOf course this also means that I can’t charge in this configuration due to only having 2 USB-C\nports. For any longer term use, you would certainly want a USB-C Hub to solve that.
\nSo configuration #2 consisted of the following
\nUni USB-C to HDMI adapter to AOC 27\" monitor
Uni USB-C to HDMI adapter to AOC 27\" monitor
I had to plug in the 2nd monitor twice as the first time it wasn’t recognized by Chrome OS. The\nsecond time it worked fine and was available in the Display settings. I was able to set up the\nmonitor positioning (each 27\" on one side of the PB’s internal display. This was quite a nice\nexperience.
\nThe first thing I tried was to move an open Chrome window from my PB’s internal display to one of\nthe external monitors. This crashed Chrome OS and I lost my WebStorm instance which was hosting an\nAngular CLI project and Firebase Functions.
\nI was able to open the Chrome window again and move the tab back to the external display. I have\nread online this is a common issue with Chrome OS. However, I haven’t yet tracked down the related bug\non https://crbug.com.
\nThe other issue that I ran into here, which I don’t think is restricted to external monitors, is\nthat Linux apps which are running in fully expanded windows don’t have their position remembered\nwhen they restarted. This means that I have to use an extra click every time that I open an app to\nmake it take up the full screen.
\nThese are software bugs which should be fixed. I’m not sure if the blurry scaling and lack of\nsharpness in WebStorm is 100% a software problem, but it certainly needs to be addressed by either\nthe Chrome team or JetBrains. For now, these issues make the whole external monitor experience on\nChrome OS sub-par. It’s certainly workable but, much like tablet mode, there seems to be quite a\nlot of space for improvement.
\nSome additional positive notes:
\nLetting the Pixelbook go to sleep connected to external monitors worked well. I was able to wake it\nusing a variety of options including an external mouse, external keyboard, and the Pixelbook’s\ntrackpad and keyboard. All the window positions and states were intact.
\nWhen I open certain Android apps, like SWGOH, the app appears to open in the first monitor. This\nhappens even if you launched the app from the launcher on another display. In my case, it opens in\nthe left external monitor. However, I want it to open on the Pixelbook’s internal display so that\nI can use the touch screen. There doesn’t appear to be a way to move a full screen app like this\nfrom one display to another. It’s impossible to take the app out of full screen mode either via\nthe mouse cursor, or the full screen button on the Pixelbook. There are some\narticles about shortcuts for moving windows across displays,\nbut they reference the out of date Launcher+Alt+Arrow shortcut.
The shortcuts for snapping windows to the left/right half of the screen\nwith alt+[ or alt+] work for me, but that’s not what I want to do here, and they don’t work with\nfull screen Android apps like this.
Finally, I decided to open the Chrome OS shortcut search panel via Launcher+Alt+/. Then searching\nfor “move” immediately showed me the proper shortcut: Launcher+Alt+m. This works!
Like a number of functions in Chrome OS, a keyboard shortcut is the only way to access the\nfunctionality, and the discoverability of this functionality is poor.
\nI mentioned in a day 3 that the Google Cloud Tools plugin login didn’t work due to the redirect not\nbeing mapped between Crostini and Chrome OS. This wasn’t the case for logging in from the Firebase\nCLI via firebase login. Everything worked smoothly there. I also tried the Google Cloud SDK via\nthe gcloud auth login command and that worked well.
On the Pixelbook, I always saw an accumulation of the same error in my browser console when I have\na site open in live reload (dev) mode:
\nUnchecked runtime.lastError: The message port closed before a response was received.\nI’m not sure what is causing this or how to solve it. However, it does not appear to be causing a\nsignificant issue.
\nI did some performance tests with Angular CLI v7.1.0. Eventually, I decided to test against a\nbrand new ng new project. I used the existing project only for build times, but not reload times\nas they were too funky due to the project using a number of different libraries. For comparison, I\nincluded some numbers from my primary dev machine: a mid-2014 i7 16GB RAM 256GB SSD MacBook Pro.
Time to run ng serve: ~16s
Time to refresh the browser on a page served via ng serve: ~1s
Round trip for making a change and seeing it live in the browser: ~2–3s
\nProduction build time: ~33s
\nI had to throw out the browser refresh and round trip times here due to an issue with this project\nthat caused both platforms to run much slower than they should.
\nWhat about that production and dev build times though?
\nProduction build: ~3 minutes
\nDev Build: ~29s
\nFor the production build, looking at the CPU cores in Cog, a few of the longer running tasks like\nthe TerserPlugin have significant portions that run on a single CPU. When this happened, the\nother CPUs were hanging around 5–25% while one CPU was around 90–100%.
This was done on battery power and none of these tests really drove up the thermals in any\nsignificant way. Everything continued to run around 105–140F.
\nI also tried and AngularJS project that just uses Gulp and gulp-connect. In this case the build\ntook ~22s and live reload did not work at all. On the MacBook Pro, this project builds in ~17s.\nThis app also had the same console errors.
By default, the app used http://localhost:35729/livereload.js?snipver=1 for live reload. I was\nable to get gulp-connect livereload working using the following config:
livereload: { hostname: ‘penguin.linux.test’ },\nThis did not fix the console errors, but it fixed live reload.
\nI wanted to provide some comparable times for the above data points in the same project on\nmy 2014 MacBook Pro. These are numbers that I’m mostly fine with and would like to see equaled or improved\nupon by a new laptop.
\nTime to run ng serve: ~10s
Time to refresh the browser on a page served via ng serve: ~1.5s
Round trip for making a change and seeing it live in the browser: ~2–3s
\nProduction build time: ~26s
\nProduction build: ~2m 19s
\nDev Build: ~26s
\nOn Android, one of the slowest tasks that I do with apps is opening up SWGOH.
\n![\"Load](\"/large-images/swgoh-load-time-chart.png\")
Here’s the data:
\n![\"Pixelbook](\"/large-images/pixelbook-macbook-pro-perf-compared-chart.png\"){kind=tracking}
The Pixelbook was 10–40% slower for CPU intensive tasks like running builds. I was surprised that it\nrefreshed pages in dev mode approximately 0.2–0.4s faster than the MacBook Pro. This may be explained by\nthe fact that the Pixelbook is running Chrome 71 while the MacBook Pro is running Chrome 70. Or the\nPixelbook is just slightly better tuned for running Chrome?
\nThese results aren’t overly surprising. The Pixelbook is running a newer generation i7 processor,\nbut it’s also tuned for mobility and thermal performance in a laptop w/o fans. The Pixelbook is\nalso half of the price of this mid-2014 MacBook Pro.
\nOverall, performance-wise the i7 Pixelbook packs enough punch to do web, backend, and Android\ndevelopment, but it won’t blow you away with speed.
One of my goals when picking up the Pixelbook i7 16GB RAM 512 SSD was to see if it could serve as\nan effective backup development machine.
This is due to the fact that my mid-2014 MacBook Pro i7 16GB 256GB SSD w/ Intel graphics is well outside\nof it’s extended Apple Care warranty. The MacBook Pro still works great and does most everything that I need.\nI’ve found that the 256 GB SSD is a little too small for me, and I’ve run into cases where I wish that\nI had more graphics power. That said, it has proven to be an incredibly reliable, performant, and\nproductive tool over the last 4.5 years. It was clearly one of my best tech purchases, ever.
That said, there are still enough rough edges in Chrome OS and Crostini (beta) that getting things\nset up properly and keeping things running over time will be too large of a drain on my\nproductivity. This is obviously a personal decision. If you don’t have kids and find that you have\na lot of spare time in your life, then you may make the opposite choice here.
\nAnother aspect of this decision also relates to productivity. That is the speed and smoothness with\nwhich I would be able to make the transition from a temporarily or permanently disabled primary\ndevelopment machine (my MacBook Pro). While I use almost no macOS-specific apps, preferring mostly\nLinux-based apps, it is still not a simple transition for me to switch my dev environment from\nmacOS to Linux. There are a number of contributing factors here:
\nMy MacBook Pro time machine backups are on a USB-A 3.x drive that my Chromebook cannot read due to the\nMac OS Extended Volume Hard Drive Format (HFS+).
The Pixelbook does not support Thunderbolt 2 or Thunderbolt 3. So peripherals for my MacBook Pro need\nextra adapters and if I upgrade to a new MacBook Pro there will be peripherals that may not work with the\nPixelbook. This problem is especially painful when it comes to \\$300+ docking stations to support\ndual external monitors.
There are minor differences between the two systems which would cost me a good deal of time to\nmitigate. These include font and resolution settings in IDEs, differences in window management\nbehaviors and shortcuts, differences in keyboard layouts, etc.
I’ve seen some reviews out there about Chrome OS and the Pixel Slate. They mention the idea of a\nthousand little cuts. Each one may have a work around or mitigation, but taken on a whole there\nare enough of them that the total impact is significant.
\nThankfully, most of these issues are on the software side and will be improved or resolved over\ntime! I feel strongly that Chrome OS has a strong future in most all markets (even development).
\nThe Pixelbook is an amazing device for so many people today. It’s going to keep improving over time,\nespecially since it will get updates for 7 years after its launch date instead of 5 like many other\nChromebooks.
\nMost of it is amazing. The keyboard and trackpad are superstars. The overall feel is very solid and\npremium. I was happy with the thermal performance and quiet fan-free usage.
\nThe hinge worked great for me in most all cases. It has a little more movement than I’d like when\ntouched in non-tablet and tent modes. Plus you need to hold down the keyboard when opening the\nscreen. This is a hard problem. In one case I want the hinge to be more stable and in another I\nwant it to open more easily.
\nI have very positive and negative opinions on the Pixelbook’s screen. The bezels are indeed\nenormous, but it’s not a deal breaker for me. I much prefer the 3:2 aspect ratio over the wide\nscreens seen on many of laptops (Dell, etc.). This gives more vertical space for productivity\ntasks like reading, writing, or coding. The screen is impressively thin. The webcam worked well\nenough, but did not impress me.
\n\n\nThe Pixelbook has 235 pixels per inch, and my MacBook Pro has 220 pixels per inch. The Pixelbook’s\n display has 400 nits of brightness which makes it usable outdoors. My MacBook Pro only has 320 nits of\n brightness, and it doesn’t excel outdoors. That said, new MacBook Pros have 500 nits of brightness.
\n
On paper, the Pixelbook’s screen is very solid. However, in practice I found that changing\nresolution or scaling display output resulted in blurry or pixelated images and text. This was\nlikely due to Chrome OS’ Freon graphics stack, Linux apps being in beta, and Android apps not\nbeing fully tuned to Chrome OS yet. This resulted in a display experience that I wasn’t completely\nsatisfied with.
\nThe Intel Bluetooth/Wi-Fi combo chip is the primary reason that I am returning the Pixelbook. I had\nmany occurrences in Chrome OS 70 (Stable) of Bluetooth disconnecting and not auto reconnecting on me.
\nThis device has been on the market for a year now. Lately, I’ve been waiting to buy a number of\ntech products until they have been in the market for a few months. This gives me the chance to see\nwhich products have serious flaws and which have flaws that can be addressed via software updates.\nThis strategy has saved me a lot of wasted time, frustration, and money in the last 4 years.
\nThat said, the Pixelbook still having serious feature-breaking problems in the Stable channel after\na year is too much for me to ignore. Yes, I had better luck with Chrome 71 (Beta), but there are\nnumerous users who are still reporting Bluetooth issues with that build. I don’t have the luxury\nof waiting to see since the return period is only 15 days. Plus I’ve already spent as much time\ntesting this device as I can afford.
\nAdditionally, comments in the various Bluetooth\nbugs in the Chrome OS issue tracker\nseem to indicate that there is a hardware flaw or missing feature with the Pixelbook’s Intel Stone\nPeak 2 Bluetooth/Wi-Fi chip. There is some additional discussion of this issue on\nReddit.
\nIt doesn’t seem wise for me to spend \\$1,700+ on a device that has an issue like this that may never\nbe fully fixed. Bluetooth is something that I make heavy use of, so issues with this chip could\nseriously impact productivity.
\nThat combined with the many little cuts to productivity, mentioned above, resulted in me making the\ndecision to return the Pixelbook.
\nIf I can pick up the cheaper model on a big discount, then I would love to have a Pixelbook, but I\ncan’t justify keeping the top end model.
\nI will certainly continue to keep my eye on high-end Chromebooks which can be used for development.\nI’m excited by the progress and goals of Crostini. Additionally, I’m also confident Android apps on\nChrome OS will continue to improve each year. I do plan to make a Chromebook my primary development\nmachine at some time in the future.
\nUntil then, I am planning to stick with MacBook Pro devices for my primary development platform.\nI’m very happy I’m able to test my web apps on Android, macOS, iOS, Windows, and Chrome OS\nusing a MacBook Pro. You can find out more about running Chrome OS in a VM on a MacBook Pro in\nthis Twitter thread.
\nIf you haven’t checked it out yet, DevFest Florida is happening at\nDisney World’s Contemporary Resort on January 19th. The\nlist of speakers is really impressive. Tickets for students\nand professors are only $99 (plus fees) and general tickets are $175 (plus fees).
\n\n", "url": "https://devintent.com/blog/2018-11-25-my-pixelbook-dev-experience.md", "title": "My Pixelbook Developer Experience", "summary": "Head-to-head comparison of the development experiences on the Google Pixelbook and Apple MacBook Pro.", "date_modified": "2018-11-25T00:00:00.000Z", "tags": [ "chrome", "mac" ] }, { "id": "blog/2018-11-24-using-a-pixelbook-for-angular-development.md", "content_html": "If you are interested, I am happy to offer readers 25% off of general ticket prices using\nthis link!\n I hope to see some of you there.
\n
If you just received a new Pixelbook, congratulations! Hopefully you have had some fun with\nInfinite Painter and possibly some other Android apps from Google Play.
\n\n\nNote: I wrote a\nseparate, detailed post\nabout my initial Pixelbook Developer experience.
\n
Now let’s get down to the business of getting your machine ready for some Angular development!
\n![\"Running](\"/large-images/pixelbook-angular-webstorm.png\"){kind=tracking}
First, make sure you update to the latest patch by checking for an update in your status bar\n(click the clock). Select the option to reboot and install the update if one exists. Ideally you\nare on Chrome OS 70 or later.
\nYou can check your Chrome OS version in Settings->Hamburger menu->About Chrome OS.
Go to the Support Page for Linux Apps\nand follow the instructions. In my case, there were some upgrades available from apt-get.
From your Linux terminal:
\nsudo apt install openjdk-8-jdk\nGo to the JetBrains WebStorm Download page and click the\nDownload button.
\nIn your Linux terminal, create a downloads folder:
\nmkdir ~/downloads\nOpen the Files app.\nCopy your download from My files->Downloads to Linux files->downloads via drag and drop.
![\"Move](\"/large-images/chrome-os-webstorm-download.png\")
In your Linux Terminal, extract the WebStorm archive into /opt:
sudo tar xf ~/downloads/WebStorm-2018.3.tar.gz -C /opt\nIn your Linux Terminal, launch WebStorm:
\n/opt/WebStorm-183.4284.130/bin/webstorm.sh\nNote that your path to the WebStorm directory will be slightly different per version.
\nGo through the setup steps and make sure the box to create a Desktop Entry is checked (default) but\ndon’t check the box for All Users. Complete the wizard, give WebStorm a minute to settle, and then\nclose it.
\nThat last step made WebStorm available in the Linux apps directory of the Chrome OS Launcher.
\n![\"Linux](\"/large-images/chrome-os-linux-apps.png\")
Launch WebStorm from the Chrome OS Launcher and repeat the setup steps other than creating a\nDesktop Entry.
\nNow for using GitHub, you will want to setup SSH and GPG. We’ll\nstart with SSH.
\nFollow these steps\nto generate a SSH public and private key for your Pixelbook. If the part about “Adding your SSH key\nto the ssh-agent” is empty, scroll to the top and make sure Linux is selected. Then follow\nthose steps. I reported this issue to GitHub, so manually selecting Linux for Chrome OS should not\nbe required once they fix their user-agent detection.
Open GitHub SSH and GPG keys and create a new key with the\ncontents of id_rsa.pub. You can get the contents via
cat ~/.ssh/id_rsa.pub\nNow back in WebStorm, you need to set up GitHub under File->Settings->Version Control->GitHub.\nCheck the box for “Clone git repositories using ssh”. Then click “Add account”.
Fill in your username and password. It will prompt you for your 2FA code in the next step. If that\nis successful, GitHub will be configured properly.
\nIf you created your SSH key with a password (recommended), then you need to make sure the SSH\nAgent prompts you for your password after a reboot. There are many options available for doing this\ntask. We’re going to use a simple setup that uses an open source package called\nkeychain.
\nIn your Linux Terminal, install keychain:
\nsudo apt-get install keychain\nOpen your ~/.bashrc file and add the following line at the end:
eval `keychain --eval id_rsa -q`\nThis setup will prompt you for your SSH key’s passphrase only once per reboot.
\nNote: You can use vi to make this change or install something like nano if you prefer.\nRemove the -q if you want keychain to print some information every time you open a shell.\nThis comes from a couple different sources:\nStackOverflow,\nUnix StackExchange.
Check if you already have GPG2 via
\ngpg --version\nIf not, in your Linux Terminal, install GPG2:
\nsudo apt-get install gpg2\nIf you have a new Pixelbook, then you can go straight to installing GPG. If your Pixelbook is not\nnew, then you should\ncheck if you have any existing GPG keys.
\nFollow these steps\nto generate your GPG key and export it to a format for adding to GitHub.
\nSetting up a GPG key allows GitHub to show the green “Verified” label next to the commits in your\nPull Requests.
\n![\"Example](\"/large-images/github-gpg-verified.png\")
In WebStorm, checkout a Git repository:
\n![\"Checkout](\"/large-images/webstorm-checkout-from-version-control.png\")
If you successfully logged into GitHub earlier, then your repositories will be available in the URL\ndrop down.
\n![\"GitHub](\"/large-images/webstorm-github-repos.png\")
Note that the first time you clone, it should warn you about an unknown host and allow you to add\nthat host and remember it.
\nAlso make sure that you choose a directory in your home directory and not in /root/. It picked\n~/Webstorm/Projects/ for me.
If you use WebStorm on another computer, you can sync your settings there and have your Pixelbook\npick those settings up easily.
\nOn your Pixelbook, in the bottom right-hand corner of the screen, click on the Gear with the\nquestion mark. Then select “Enable Sync…”
\n![\"WebStorm](\"/large-images/webstorm-sync-settings.png\")
Select the option that works best for you. Then after a minute, you should be able to click on the\nGear again and either Sync your Plugins silently (e.g. install all the plugins that are on your\nother computer and disable plugins that are disabled on your other computer) or choose which plugins\nshould be synced and which should not.
\nAs described in the NVM docs, in the Linux\nTerminal run:
\ncurl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash\nReload your terminal to get access to NVM by running:\nsource ~/.bashrc
Now running nvm --version should output 0.33.11.
Install NodeJS LTS (Long Term Support) and the matching version of NPM by running:
\nnvm install 10\nIn WebStorm, open File->Settings->Languages and Frameworks->Node.js and NPM. Node and NPM should\nbe automatically detected. Check the box for “Coding assistance for Node.js” and press OK.
![\"NodeJS](\"/large-images/webstorm-nodejs-npm-config.png\")
Now restart WebStorm so that it can initialize some more NPM features. When WebStorm opens again, you should see a popup where you can have the IDE run npm install for you.
![\"WebStorm](\"/large-images/webstorm-prompt-npm-install.png\")
WebStorm makes it easy for you to open your package.json file and run one of the scripts provided\nby the repository.
![\"The](\"/large-images/webstorm-run-npm-scripts.png\")
Many Angular projects now require Yarn.
\nThe easy way is to do npm i -g yarn, but you can also use the following steps taken from the\nYarn Install docs for Debian:
Add Yarn’s public GPG key and repository to Debian’s package manager by running the following in\nyour Linux Terminal:
\ncurl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -\n\necho \"deb https://dl.yarnpkg.com/debian/ stable main\" | sudo tee /etc/apt/sources.list.d/yarn.list\nIn your Linux Terminal, install yarn:
\nsudo apt-get update && sudo apt-get install --no-install-recommends yarn\nCheck the installation was successful by running yarn --version which should output a version\nsimilar to 1.12.3.
Similar to above, WebStorm will prompt you to run yarn install when you open a new project that\nuses Yarn.
Please note that the steps above for WebStorm are nearly identical if you are installing IntelliJ\nIDEA or many of the other JetBrains IDEs.
\nI hope that this post is useful to some intrepid developers who are ready to get productive with\ntheir Pixelbooks! Please leave comments if you run into any issues or if something doesn’t work,\nand I will try to update this post.
\nIf you haven’t checked it out yet, DevFest Florida is happening at\nDisney World’s Contemporary Resort on January 19th. The\nlist of speakers is really impressive. Tickets for students\nand professors are only $99 (plus fees) and general tickets are $175 (plus fees).
\n\n\nIf you are interested, I am happy to offer readers 25% off of general ticket prices using\nthis link!\n I hope to see some of you there.
\n
Some information for this post was taken from the helpful\nCrostini community on Reddit.
\nI was also able to get Gimp 2.10.x installed thanks to the\nChromeOS community on Reddit.
", "url": "https://devintent.com/blog/2018-11-24-using-a-pixelbook-for-angular-development.md", "title": "Using a Pixelbook for Angular Development", "summary": "Step-by-step instructions for setting up WebStorm, Git, NodeJS, NVM, and Yarn for web development with Angular.", "date_modified": "2018-11-24T00:00:00.000Z", "tags": [ "chrome", "angular", "webstorm" ] }, { "id": "blog/2018-11-18-using-a-pixelbook-with-a-docking-station-and-extended-monitors.md", "content_html": "I have a new Google Pixelbook on the way, and\nI’m trying to figure out my docking station solution.
\n![\"Google](\"/large-images/pixelbook-usbc.jpg\"){kind=tracking}
This old, locked support forum post\nmentions the Dell D6000 dock which people have had some luck with. There\nappears to be an issue where the dock will lose connection with the monitors every couple of hours.\nThis seems to be commonly reported by users of Dell docks (across reviews of many of their existing\nUSB-C docks). I’m not sure if any of those posters using the D6000 were able to solve this issue\nor not.
\nKeith Meyers’ blog\nmentions successfully using the Pixelbook along with the\nPlugable USB 3.0 Universal Laptop Docking Station. This is a dock from 2013.
\nThe Plugable USB-C 4K Triple Display Docking Station with Charging Support\nis from 2017 and has 4K@60fps support via DisplayPort. It also supports charging the Pixelbook.
\nIn the Q&A, the Plugable states that the Pixelbook is fully supported. However, I’d like to hear from\nthe community whether you were able to get this dock working and if you ran into any\nissues.
\nAnother interesting option is the CalDigit USB-C Docking Station. It only\nsupports two monitors, but that is sufficient for me. For two monitors, you need to use\nDisplayPort Multi-Stream Transport\nwhich Chrome OS added support for in the Spring of 2018. This means that the DisplayPort port would\ndrive both monitors, and the HDMI port would be unused. Since my monitors are HDMI, I would need to\nuse a MST Hub to split the signal and then DP->HDMI adapters.
\nThis CalDigit setup seems a bit involved and possibly slightly risky. I’d love to know if\nanyone has gotten it to work this year.
\nAre you using another dock that you’ve found works great for you? Please let me know.
", "url": "https://devintent.com/blog/2018-11-18-using-a-pixelbook-with-a-docking-station-and-extended-monitors.md", "title": "Using a Pixelbook with a docking station and extended monitors", "summary": "Research and discussions of using a docking station with a Google Pixelbook.", "date_modified": "2018-11-18T00:00:00.000Z", "tags": [ "chrome" ] }, { "id": "blog/2018-06-28-announcing-the-angularjs-material-v1-1-10-release.md", "content_html": "We have released AngularJS Material v1.1.10.
This release is now available in our\nOnline Documentation, NPM,\nand Bower. It is also available on the Google CDN (JS, CSS).
\nYou can find the details for all releases in our\nChange Log.
\nv1.1.10 should be our most stable release in many months. Here are some highlights:
Fixed four significant regressions to chips that were introduced in 1.1.2 and 1.1.9. Two of these were also a11y issues.
Fixed a memory leak when elements using md-theme are removed from the page
Fixed select to support selecting options by typing when the option contains a period (i.e. 255.255)
Improved dark mode theme support for menu-bar and datepicker
Fixed ripple animations getting stuck on iOS in certain situations
Fixed a couple layout issues
Significant improvements to the project’s documentation including 3 new demos
![\"New](\"/angularjs-material/md-calendar.png\")
![\"Moment.js](\"/angularjs-material/md-datepicker-moment.png\")
This is a patch release with non-breaking changes (fixes and enhancements).
\nchips: editable chip gets removed after editing
chips: improve ability to receive focus on click
chips: regression where chips model gets out of sync with view
chips: unwanted re-focus of last chip after blur
compiler: remove dependency on AngularJS private API
datepicker: calendar panel theme supports dark mode in multi theme scenario
layout: allow flex-offset to be a child of layout-margin
layout: reduce layout CSS size by reverting some of #11247
menu-bar: md-menu-bar panel theme supports dark mode themes
nav-bar: missing [disabled] scss selector
ripple: fix iOS Safari stuck ripple issue
select: doesn’t search correctly when pressing period character
theming: md-theme leaks when child elements are removed
ng-trimdatepicker: fix typos, general clean up, add calendar demo, add moment.js demos
dateLocaleProvider: add missing documentation for isDateComplete() and longDateFormatter()
virtual-repeat: fix typos, clean up, and clarifications
tabs: add link to tab docs, clarify the notes about nav-bar
select: clarify the behavior of the multiple attribute
Thank you to the\ncontributors,\nespecially the first timers, who helped with the v1.1.10 release:
\n![\"AngularJS](\"/angularjs-material/1-1-10-contributors.png\")
You may have read about a\nrecent study\nthat came out in early September 2017 by the Nielsen Norman Group. It had a headline grabbing title\nabout how Flat UI designs cause uncertainty in users. The headline alone had product managers\nquestioning their designers and developers.
\nHowever, if you read deeper into the article, you’ll find that the eye tracking research actually\nconfirmed the importance of a number of key UI design guidelines.
\nIf you are building user interfaces and you haven’t embraced the acronym\nCRAP yet, then I\nhighly recommend that you look into it.
\nIt stands for Contrast…. your important, interactive UI elements need to stand out.
\nRepetition… consistent UI patterns train user’s brains where to look.
\nThen you build a clear visual hierarchy through the use of Alignment and Proximity.\nThis includes intelligent use of negative space (or whitespace) along with grouping items that\nbelong together near each other.
\nThis study hits on a key human factors issue. Complex, high density user interfaces cause users\nuncertainty and delay their ability to take action.
\nNow let’s take a look at some details of the study and how Material Design is already built to address\nthese challenges.
\n![\"Example](\"/large-images/flat-ui-example.png\")
On the left, we see a traditional link with the blue color and underline. The right side shows an\nexample of an ultra-flat UI where positioning is the only signifier that the element may be interactive.
\nThe eye tracking results showed that users of the flat design would try to click on the header first\nand often ignore the flat button completely because it’s click ability signifiers were too weak.
\n![\"Example](\"/large-images/flat-button-example.png\")
Material Design provides a number of different button types to address this type of situation. First\nthere is the flat button. It stands out through the use of a contrast color in addition to\ncapitalization. However, these buttons are not designed to be used for your more important actions.
\n![\"Example](\"/large-images/raised-button-example.png\")
In this case, taking the user to your pearl storefront is a primary action.
\nMaterial Design provides raised buttons for the cases where you want a strong click ability signifier,\nand the user’s gaze to be attracted by the color and height of the button.
\nIn my next post, I’ll discuss the basic concepts of Material Design and try to distill the\nmarketing and design language into something that a developer can make sense of.
\nIf you don’t want to wait, you can start reading the\nMaterial Design Specifications now.
", "url": "https://devintent.com/blog/2018-03-28-eye-tracking-study-finds-problems-with-flat-uis.md", "title": "Eye Tracking Study finds problems with Flat UIs", "summary": "Discussion of how an eye tracking study's results apply to Material Design.", "date_modified": "2018-03-28T00:00:00.000Z", "tags": [ "material-design" ] }, { "id": "blog/2018-01-28-angularfire2-5-0-0-rc-6-released.md", "content_html": "AngularFire2 has released 5.0.0-rc.6 for apps built with Angular.
This release brings support for the typing changes in Firebase JS SDK 4.8.1+ and much awaited support for Firebase Cloud Storage!
\n![\"Firebase](\"/icons/firebase-storage-icon.png\"){kind=icon}
Many thanks to @_davideast, @jamesuriah, and a number of community contributors for helping get this update out!
\n![\"AngularFire2](\"/large-images/angular-fire-5-0-0-rc-6-changelog.png\")
Full changelog here.
\nIf you run into an issue using Phone Auth due to the types of firebase.app.App and FirebaseApp no longer agreeing like this:
ERROR in src/app/auth/auth.component.ts(67,5): error TS2345: Argument of type 'FirebaseApp' is not assignable to parameter of type 'App'.\n Types of property 'auth' are incompatible.\n Type '() => FirebaseAuth' is not assignable to type '() => Auth'.\n Type 'FirebaseAuth' is not assignable to type 'Auth'.\n Types of property 'app' are incompatible.\n Type 'FirebaseApp' is not assignable to type 'App'.\n Types of property 'auth' are incompatible.\n Type '() => FirebaseAuth' is not assignable to type '() => Auth'.\n Type 'FirebaseAuth' is not assignable to type 'Auth'.\nAdd the new @firebase packages to your package.json:
\"@firebase/app\": \"0.1.7\",\n\"@firebase/auth\": \"0.3.2\",\nChange your firebase import
import * as firebase from 'firebase/app';\nto use the new format (with the default export syntax)
\nimport firebase from '@firebase/app';\nThis may then spit out the following error
\nerror TS2503: Cannot find namespace 'firebase'.\nFor me, this was caused by setting the following type
\nphoneRecaptchaVerifier: firebase.auth.RecaptchaVerifier;\nYou can solve this by using the new @firebase/auth-types package
import { RecaptchaVerifier } from '@firebase/auth-types';\nThen just remove the firebase.auth. so that you have the cleaner version
phoneRecaptchaVerifier: RecaptchaVerifier;\nNote: when calling a constructor like new firebase.auth.RecaptchaVerifier(), you’ll still need the\nfirebase.auth. prefix.
This article assumes that you are using SCSS with the Angular CLI.
\n![\"Material](\"/large-images/material-design-layers-logo.png\"){kind=logo}
![\"Duplicate](\"/large-images/angular-material-duplicate-styles.png\")
You can see the .mat-toolbar.mat-primary style at the top. Then you can see it down below once\nmore. This time with the same exact styles (background, color) and values, but all of them\noverridden.
In this example, there is only 1 duplicate set of styles, but it is very easy to\nsuddenly see 3 duplicate sets or 5 or more! As you might imagine, this can significantly impact your\nbundle size in addition to complicating the styling of your app.
\nNow show some examples to showcase how easy it is to get into this situation…
\nA typical theme file will look something like this:
\nstyles.scss:
\n@import '~@angular/material/theming';\n// Plus imports for other components in your app.\n\n// Include the common styles for Angular Material. We include this here so that you only\n// have to load a single css file for Angular Material in your app.\n// Be sure that you only ever include this mixin once!\n@include mat-core();\n\n// Define the palettes for your theme using the Material Design palettes available in palette.scss\n// (imported above). For each palette, you can optionally specify a default, lighter, and darker\n// hue.\n$candy-app-primary: mat-palette($mat-indigo);\n$candy-app-accent: mat-palette($mat-pink, A200, A100, A400);\n\n// The warn palette is optional (defaults to red).\n$candy-app-warn: mat-palette($mat-red);\n\n// Create the theme object (a Sass map containing all of the palettes).\n$candy-app-theme: mat-light-theme($candy-app-primary, $candy-app-accent, $candy-app-warn);\n\n// Include theme styles for core and each component used in your app.\n// Alternatively, you can import and @include the theme mixins for each component\n// that you are using.\n@include angular-material-theme($candy-app-theme);\nNow if this is all you do, you won’t run into problems, even if you ignore most of the comments.
\nHowever, we all know that real production apps need to integrate this code into a much more complex\nsystem. For instance, the full Angular Material theme may not be included in the App Shell (used to\nquickly paint the screen and let users on low bandwidth devices know that your app is bootstrapping).
\nIn this article, we’ll use https://angular.io and its code as an example since\nmany developers look at this AIO repo and copy\nthe code from it into their own apps.
\nng-io-theme.scss:
\n@import '~@angular/material/theming';\n// Plus imports for other components in your app.\n\n// Include the base styles for Angular Material core. We include this here so that you only\n// have to load a single css file for Angular Material in your app.\n@include mat-core();\n\n// Define the palettes for your theme using the Material Design palettes available in palette.scss\n// (imported above). For each palette, you can optionally specify a default, lighter, and darker\n// hue.\n$ng-io-primary: mat-palette($mat-blue, 700, 600, 800);\n$ng-io-accent: mat-palette($mat-red, 700, 600, 800);\n\n// The warn palette is optional (defaults to red).\n$ng-io-warn: mat-palette($mat-red);\n\n// Create the theme object (a Sass map containing all of the palettes).\n$ng-io-theme: mat-light-theme($ng-io-primary, $ng-io-accent, $ng-io-warn);\n\n// Include theme styles for core and each component used in your app.\n// Alternatively, you can import and @include the theme mixins for each component\n// that you are using.\n@include angular-material-theme($ng-io-theme);\nThere’s a very important comment that has been removed from this version.\n// *Be sure that you only ever include this mixin once!*
Now if you miss that, and you use some other examples like the following, you may start to see\nduplicate styles and even need to resort to !important on many of your styles that target Angular\nMaterial classes like .mat-form-field or .mat-raised-button.
I have run into apps with these issues, and it has resulted in 500 kB to 1.5 MB of bloat in the\ndeveloper build of the site. In production builds the impact is smaller, but every kB counts when\nshooting for great WebPageTest or\nLighthouse scores!
\nmain.scss:
\n// import global themes\n@import '~@angular/material/theming';\n@import './ng-io-theme';\n\n// import global variables\n@import './constants';\n\n// import global mixins\n@import './mixins';\n\n// import directories\n@import './0-base/base-dir';\n@import './1-layouts/layouts-dir';\n@import './2-modules/modules-dir';\nYou can see here that main.scss is including ng-io-theme.scss which includes @include mat-core();.
styles.scss:
\n/* You can add global styles to this file, and also import other style files */\n@import './styles/ng-io-theme';\n@import './styles/main.scss';\nYou can see here that styles.scss is including ng-io-theme.scss as well. Then including\nmain.scss which also includes @include mat-core();. There is another include here that is\ngetting duplicated as well, @include angular-material-theme($ng-io-theme);.
The AIO repo uses considerably more (custom scripts, rollup, etc.) than just the Angular CLI to\nbundle and deploy their application. I wasn’t able to determine exactly how they avoid duplicate\nAngular Material styles with this setup, but I did verify that there are not any duplicate Angular\nMaterial styles on the production site.
\nYou probably want to stick closer to the Angular CLI only approach for your own apps as long as you\ncan. So I’ll provide an example to use in that case.
\nstyles.scss:
\n@import './styles/theme';\n\n// Include the base styles for Angular Material core. We include this here so that you only\n// have to load a single css file for Angular Material in your app.\n// Be sure that you only ever include this mixin once!\n@include mat-core();\n\n// Include theme styles for core and each component used in your app.\n// Alternatively, you can import and @include the theme mixins for each component that you are using.\n@include angular-material-theme($app-theme);\n\nhtml {\n...\nThis is the src/styles.scss file found in Angular CLI projects with SCSS enabled.
Styles in this file are applied globally without any ViewEncapsulation.
This file is included in your app only once via the .angular-cli.json file via\n“styles”: [“styles.scss”].
You should not import this file into any other SCSS file.
The Angular Material @include statements should be in this file.
Note: If you are using an App Shell for your app, the Angular Material @include statements\nare probably in another file. Just make sure that it is only included once.
However, this file is free to include other SCSS files like your src/styles/_theme.scss found below
_theme.scss:
\n@import '~@angular/material/theming';\n\n// Define the palettes for your theme using the Material Design palettes available in palette.scss\n// (imported above). For each palette, you can optionally specify a default, lighter, and darker hue.\n$app-primary: mat-palette($mat-teal, 700, 100, 900);\n$app-accent: mat-palette($mat-orange);\n\n// The warn palette is optional (defaults to red).\n$app-warn: mat-palette($mat-red);\n\n// Create the theme object (a Sass map containing all of the palettes).\n$app-theme: mat-light-theme($app-primary, $app-accent, $app-warn);\nIn this file we define the $app-theme variable that is later used in src/styles.scss.
Note: We’re using a feature of SCSS here that is called “Partials”. You can find out more about\nthem in this StackOverflow answer or in\nthe official SASS docs. Note that the _ in the filename is very\nimportant here and changes the behavior of SASS.
Now this file can be imported in many places in your app to give you access to variables like\n$app-accent for use in a statement like the following without duplicating styles.
app.component.scss:
\n@import '../../styles/theme';\n\n.noRecordsContainer {\n padding: 48px;\n background-color: mat-color($app-accent, 50);\n width: 100%;\n}\n\n.errorMessageContainer {\n padding: 48px;\n background-color: mat-color($app-warn, 50);\n width: 100%;\n}\nThis lets you use your Material Design palette in your custom components. In this case, we’re using\nthe lightest accent color (50) as the background of the container which provides a message about\nthe empty search result set. We’re also using the lightest accent color of the warn palette as the\nbackground color of our error panel.
These are just two very simple examples of the powerful capabilities of using SCSS along with the\nAngular Material Theming system. Find our more in their\nguide to theming your own components.
\nBe careful of how you set up SCSS in your Angular Material and Angular CLI project. It can lead to\nbloat and styling complications.
Follow the architecture above to eliminate duplicate styles if you have them
Brush up on the basics of SASS and the capabilities of the\nAngular Material Theming system
Keep leveraging these great tools to build amazing high performance web applications with solid UX!
I hope that you find this helpful. If you would like to see more Angular Material content, please\nlet me know.
\nThere will be some great presentations next week (Oct 10–12th) at\nAngularMix in Orlando, FL USA. I’ll be presenting\n“Delight your Organization with Material Design”\non 10/12. There will be many other talks including Angular’s new Component Dev Kit (CDK), which\nAngular Material leverages, and Angular CLI’s new DevKit and schematics.
\nTickets are still available, and you can get \\$100 off with the code MIXPRENTICE! They include an\nafter party at the Wizarding World of Harry Potter in Universal Studios Orlando. I hope to see you\nthere!
\n\n#Angular v4 upgrade in one Tweet. Only missing the updates to package.json versions. https://t.co/BlxP6VBu6B
— Michael Prentice (@Splaktar) March 24, 2017
\n\nUpdate app.module.ts:
— Michael Prentice (@Splaktar) March 24, 2017
import {BrowserAnimationsModule} from '@angular/platform-browser/animations';
imports: [BrowserAnimationsModule, ...]
For most projects not using Angular Universal, it’s just that easy to upgrade from Angular v2 to Angular v4!
\nThe blog post announcing the release contains details on the new features, performance improvements, and the upgrade path.
\nAnimations pulled out of core for performance, separation of concerns
*ngIf supports and else syntax
*ngFor supports an as syntax to assign local variables
Angular Universal is now officially part of Angular core
TypeScript 2.1+ support
Improved template error messages
Thankfully the Angular CLI update from 1.0.0 RCs to 1.0.0 final is also quite straightforward. The changelog for the updates is useful reading, but what you really need is their excellent migration guide!
\nObviously if you are using the CLI, then the migration guide is where you should start. It will handle everything you need regarding upgrading both the CLI and Angular.
\n![\"Angular](\"/large-images/angular-cli-promo.png\")
If you do run into issues with your upgrade, then this interactive Angular Upgrade Guide may help you. Note that this guide is just getting started and will improve over time.
\nIf you see warnings about typing checking being required when linting via the CLI, just update your link command to the following:
\n\"lint\": \"ng lint --type-check\"\nI also ran into issues with the CLI’s production builds due to template validation.
\nOne issue was regarding static variables in my components. Using these in templates results in an error that the property does not exist. I converted those variables to nonstatic as a temporary work around.
The other was related to checking that a string variable in an object was defined inside of *ngFor. This threw a very confusing template error (with the wrong line number). I was able to work around this by moving the checks into the component and assigning the result to a boolean which was then used in the template.
Type 'string' is not assignable to type 'boolean'\nI’m waiting for some feedback before opening bugs for these last two issues.
\nIf you run into issues not found in these guides, please post a question to StackOverflow.
", "url": "https://devintent.com/blog/2017-03-24-angular-v4-final-and-angular-cli-v1-final-released.md", "title": "Angular v4 Final and Angular CLI v1 Final Released!", "summary": "Details about the Angular v4 and CLI v1 Final releases.", "date_modified": "2017-03-24T00:00:00.000Z", "tags": [ "angular-cli", "angular" ] }, { "id": "blog/2016-12-20-state-of-angular-universal-and-aot.md", "content_html": "I’ve spent a good deal of the last week looking at\nAngular Universal and Ahead of Time (AOT) compilation.\nUntil now, I had been waiting to dig into them because it was clear they were still in the\nexperimental/alpha stages.
\nHowever, I decided that I want to update the DevIntent website from\nAngular 1.5.7 to the latest version of Angular over the Christmas break!
Since this is a marketing website, I need it to be super fast, especially on mobile, and have\nexcellent SEO! I’m also using this as a testing ground for some work on an upcoming client project.
\nTimes listed for No throttling / Regular 3G.
\n36 requests
1.2 MB
459ms / 3760ms DOMContentLoaded
920ms / 13850ms Load
This is fairly typical of a smaller Angular 1.5.x application that is using a few libraries\n(Angular Material, Font Awesome, etc.) and is hosted on Firebase Hosting. It’s fine on desktop with\nbroadband internet, but not good enough on a mobile 3G device.
\nMy first choice is generally the Angular-CLI because I believe in what they are doing to make Angular\nmore approachable to new users. I use it as much as I can so that I can provide feedback, open bug\nreports, and even submit PRs.
\nThe first step was to see if Universal and AOT was working yet in the CLI. I found that they were\nboth working, just not together. The Angular-CLI does not support\nAngular Universal. It does support AOT, but there are around\n63 open issues\nrelated to AOT.
\nThere is a separate fork for a version of the CLI that\nsupports Universal, but it doesn’t support AOT.\nIt appears that they created this fork because the Angular-CLI team didn’t have the resources to\nsupport Universal.
\nFrom the latest presentations that I’ve seen at conferences, I knew that there were a number of great\nAngular seeds out there.
\nThe first one I looked at was angular-seed from\nMinko Gechev. It is really well-known, has 3,344+ stars, and supports AOT, Docker, etc. Unfortunately\nit doesn’t support Angular Universal or\nWebpack. After using Webpack with the\nAngular-CLI, I decided that I don’t want to use another bundler in my non-Angular-CLI projects.
\nI checked into Universal Starter from the Angular\nUniversal team. It uses Webpack and has basic support for AOT. But it is really minimal and doesn’t\ninclude support for SASS/SCSS. I decided\nthat I might come back to it.
\nAngular2-Webpack-Starter from\nAngularClass was another that caught my eye since it obviously supported Webpack, but it also had\na lot of the other stuff ready to go. This included Router, HTTP, Forms, Hot Module Reload (HMR),\nAsync/Lazy Routes, Material Design, and tests! It also has a great list of guides and tips like\nsetting up SASS/SCSS.\nUnfortunately, it doesn’t yet support\nAOT compilation or\nAngular Universal.
\n\n\nFound a number of seeds w/\n#AngularUniversal\nsupport, but they all seem to be broken (#ngMaterial2 / #AOT) or stuck on #Angular 2.1.
— Michael Prentice (@Splaktar) December 15, 2016
I settled on giving Anthony’s (qdouble)\nfork of angular2-webpack-starter a shot. It\ncombines all the great stuff from the original angular2-webpack-starter with support for AOT and\nUniversal! One thing I quickly noticed was that the project is stuck on an older version (v2.1) of\nAngular (latest is v2.3).
After a lot of research, it became obvious that changes to Angular core in v2.2 and v2.3 broke\nAngular Universal. Apparently the Angular core team has realized that this is a problem.
\n\n\nBut I just saw this\nhttps://t.co/eJtyJEVZrw which mentions that #Universal is moving to angular core. #ngMaterial2 is waiting on the move.
— Michael Prentice (@Splaktar) December 14, 2016
Because of this, they decided a couple weeks ago to move key pieces of Angular Universal into the\nAngular core. Unfortunately, a number of key people have been on vacation since this decision\nwas made. So we’re stuck in this state where using Angular Universal means staying on Angular v2.1.
This also means that support for Angular Universal in a new version of Angular will have to wait for\nat least v4 which just entered beta.0.
\n\nAngular 4.0.0-beta.0 is out. You're\nwondering why it's Angular 4? Read about the reasoning behind here:\nhttps://t.co/9AhXTMnlXc #angular
— Juri Strumpflohner (@juristr) December 15, 2016
The main purpose of the chosen seed/starter is performance (i.e. Angular Universal, Webpack 2, and\nAOT compilation). I checked the README for some stats for nerds (i.e. perf goodies) but sadly found\nnone. Thus, I set to gathering some performance stats on the current build of the starter.
\n\n\nnpm start
\n
\n\nnpm run universal
\n
\n\nnpm run compile + npm run prodserver
\n
\n\nnpm run universal:aot or npm run compile:universal+ npm run prodserver
\n
Chrome 57.0.2951.0 canary (64-bit)
Cache disabled
MacBook Pro (Retina, 15-inch, Mid 2014)
2.8 GHz Intel Core i7
16 GB 1600 MHz DDR3
OS X El Capitán 10.11.6 (15G1212)
NodeJS 6.7.0
Now I know that Universal and AOT are still undergoing a lot of breaking changes and needed\nimprovements, but I found it a little odd that the combination (Universal + AOT) was slower than the\nbuild with AOT alone.
\nSince the angular-cli isn’t supporting Universal + AOT yet, I was looking to find a solid seed for\nUniversal, AOT, Webpack 2, Material 2, SCSS, etc. and this one seems to be the closest that I can\nfind which isn’t significantly broken.
\nWith the numbers above, I was wondering if I should even bother with Universal at this point.\nThen I thought, well Universal should help get that initial paint a lot faster. But on any network\nwith 3G+, the time between initial paint and interactivity is under 50ms and isn’t even noticeable.\nIf I drop down to Regular 2G, then I do see the initial DOM loaded for about 2s before JavaScript\ntakes control and the page is re-rendered and fully ready for interaction.
\nPerhaps part of this issue is that the app doesn’t have an appShell (it’s just a white “Loading…”\npage), but either way I’m not sure I should go to the extra trouble of running a NodeJS server\nfor Universal at this point. I could just host a client-only app in Firebase Hosting using their\nEdge CDN w/ AOT and maybe that would be even faster than the numbers above.
\nSEO is something that I really need, but I’m not convinced that Universal will work properly here\nand deliver the desired results. There’s some\npossible hacks discussed in the\nuniversal-starter project where the meta tags can be manipulated. However, Angular’s new\nMeta Service just landed in Angular v4-beta.0\nthanks to Dzmitry Shylovich! Unfortunately Universal isn’t compatible with the latest versions of\nAngular yet.
It appears that I should just stick with AOT compilation and wait until Universal gets better\nsupport from the Angular core team (in progress, no ETA).
\nThankfully the chosen starter makes that a\nwell-supported option in addition to supporting these configurations used in the benchmarks above.\nThis is what enabled the ability to gather these numbers using different approaches, while keeping\nthe code-base exactly the same. Thanks to Anthony for the hard work\non this starter and for sharing what’s been working for him on his projects!
", "url": "https://devintent.com/blog/2016-12-20-state-of-angular-universal-and-aot.md", "title": "What’s the state of Angular Universal and AOT?", "summary": "The state of Angular Universal and AOT as of the end of 2016.", "date_modified": "2016-12-20T00:00:00.000Z", "tags": [ "universal", "angular" ] }, { "id": "blog/2016-10-22-upgrade-from-angular-2-rc4-to-final-with-angular-cli.md", "content_html": "I’ve completed the RC4 => 2.1.2 upgrade for one proprietary app and one\nopen source app. Even with experience, this process is far from\nefficient or problem-free with the various libraries, modules, and systems breaking or otherwise\naffecting each other.
It’s clear the Angular 2 Release Candidates were actually Alphas and what we’re using now in\n2.1.1 is Beta. You could say that the Angular Core is in Release Candidate state currently, but\nthe ecosystem of semi-mandatory modules that make up the platform are mostly in some form of Alpha\nor Beta.
If you update your version of the CLI first from beta.10 to beta.19, you may see this error message:
![\"Error](\"/large-images/error-old-cli-version.png\")
Note that there is an updated guide here:\nhttps://github.com/angular/angular-cli/wiki/Upgrading-from-Beta.10-to-Beta.14
\nI also submitted a PR to improve the grammar of\nthis upgrade warning message.
\nThe first step of this helpful guide is to make sure that you are up to Angular RC6 or greater. So\nyou would then find that you need to upgrade from Angular RC4 to the latest which includes the major\nbreaking change of ngModules announced in\nthis blog post.\nThis blog post announcing Angular RC5 includes a really helpful link to a migration guide.\nUnfortunately, that migration guide\n(https://angular.io/docs/ts/latest/cookbook/rc4-to-rc5.html)\nis a 404 on the Angular.io docs site.
There was a\nReddit\ndiscussing this lost migration guide, but it doesn’t point to a new location.
\nThere is\nStackOverflow question\nthat poses this exact question, but it’s first suggested solution appears to be the most time\nintensive option… review the changelogs for RC5, RC6, RC7, and final for breaking changes and\nthen make adjustments to your project. The second option here is one that I have been considering,\ngenerate a new project with the latest angular-cli beta.19 and then pull that configuration into\nyour existing project.
After quite a bit of looking, I didn’t really find something that I was happy with. A few guides hit\nabout 25% of what I needed, but I couldn’t find anything that was much more complete.
\nI highly suggest reading the following before starting:
\nThe first is the\nAngular team blog post\nthat covers the reasons why ngModule exists and how it helps you.
\nThen the official docs on ngModule\ncover some key patterns like having a\nCore Module and\nShared Module. It also covers\nlazy loading modules.
\nThis step involves just creating a single module and adding everything to it. This makes sense for\nsmall to medium-sized projects. If your project is already large, you’ll want to move on to the next\nstep.
\nBasically this step just involves using the docs links above to create your AppModule and plumb\neverything together.
\nAfter you’ve got an ngModule, you’ll need a lot less boilerplate. Unfortunately, you (or angular-cli)\nalready wrote it, so you’ll have to go and remove it now. This includes changing all of your\ncomponents by removing their directives, providers, pipes, and lots and lots of imports that aren’t\nneeded anymore.
\nUse the docs on creating a\nShared Module and move your application-wide services and common Angular modules (FormsModule,\nRouterModule, etc.) into this new SharedModule.
\nNow you’ll want to think about your project and find out if it makes sense to break up specific\nroutes into lazily loaded modules. Ideally, your module that is bootstrapped at the root of your\napp should be as lean as possible. Once you’ve identified these modules, it’s time to create them\nand start setting up the\nlazy loading in the router.
\nOK, now you’ve setup ngModules and updated your package.json to use @angular/xxx: 2.1.2, you\nare ready to proceed with the\nangular-cli migration guide.\nCarefully follow the guide, and you will be about 90% of the way there.
Many people noticed that their favicon and 404 pages weren’t showing up in dist/ after upgrading.\nThe community filed numerous bugs, but in beta.19 this was fixed. Make the changes below to take\nadvantage of this new feature that allows specifying an array of assets.
angular-cli.json (old)
\n\"assets\": \"assets\",\nangular-cli.json (new)
\n\"assets\": [\n \"assets\",\n \"elements.html\",\n \"404.html\",\n \"favicon.ico\",\n \"manifest.webapp\",\n \"icons\"\n],\nObviously the contents of this array will be specific to your application.
\nTheir getting started guide\nprovides the minimal level of help required to get this working. This has changed quite a bit from\nwhat was found in the RC5 blog post. There is now a single MaterialModule that you need to load.
\nsrc/app/app.module.ts
\nimport { MaterialModule } from '@angular/material';\n\n@NgModule({\n imports: [MaterialModule.forRoot()],\nIf you are using any of their sliders, you’ll need to import hammer.js with the new angular-cli process.
\nangular-cli.json
\n{\n \"scripts\": [\"../node_modules/hammerjs/hammer.js\"]\n}\nAdditionally, material2 now has a theming system which you will need to configure for the styling\nof your UI components to look good (i.e. not be mostly grey). See their theming guide\nhere to set this up.
\nIf you are using the Firebase SDK (required for many features like Firebase Storage that aren’t yet\nsupported in AngularFire2) then the way that you load that library has changed in the angular-cli.
\nMake sure you don’t also include the @types/firebase definitions in your package.json.
angular-cli.json
\n{\n \"scripts\": [\"../node_modules/firebase/firebase.js\"]\n}\nTheir docs\nare quite helpful, but they only covered about 95% of what I needed to do. That last 5% was pretty\npainful as what I got working in angular-cli beta.17 needed more tweaking with beta.19.
For just using AngularFire2 without Firebase Auth, you can do this:
\nsrc/app/app.module.ts
\nimport { AngularFireModule } from 'angularfire2';\n\nconst firebaseConfig = {\n apiKey: '<your-key>',\n authDomain: '<your-project-authdomain>',\n databaseURL: '<your-database-URL>',\n storageBucket: '<your-storage-bucket>'\n};\n\n@NgModule({\n imports: [\n BrowserModule,\n AngularFireModule.initializeApp(firebaseConfig)\n ],\nIf you’re using Firebase Auth, you’ll need a bit more. They cover this in their\nAuth docs.
\nI submitted a PR to help make\nthese docs a little more straightforward.
\nsrc/app/app.module.ts
\nimport { AngularFireModule, AuthProviders, AuthMethods } from 'angularfire2';\n\nconst myFirebaseConfig = {\n apiKey: '<your-key>',\n authDomain: '<your-project-authdomain>',\n databaseURL: '<your-database-URL>',\n storageBucket: '<your-storage-bucket>',\n}\n\nconst myFirebaseAuthConfig = {\n provider: AuthProviders.Google,\n method: AuthMethods.Redirect\n}\n\n@NgModule({\n imports: [\n BrowserModule,\n AngularFireModule.initializeApp(myFirebaseConfig, myFirebaseAuthConfig)\n ],\n**Troubleshooting\n**I needed to do a bit more here to deal with some TypeScript issues. Their\nexisting docs\nhere seemed to be designed for an older version of the angular-cli. I needed to remove\n@types/firebase from my package.json and use the typedefs from the Firebase SDK.
src/tsconfig.json
\n\"files\": [\n \"../node_modules/firebase/firebase.d.ts\"\n]\nIf you are on the new AngularFire2 beta.6, this step is not needed since these typedefs are included\nin AngularFire2. Adding them again here will cause many duplicate type errors.
\nThe docs here are\nquite comprehensive and once I followed them, everything seemed to just work. The main change is\nrelated to ngModule.
\nThey also fixed some pesky bugs in the latest v0.15.0 release.
\nsrc/app/app.module.ts
\nimport { AgmCoreModule } from 'angular2-google-maps/core';\n\n@NgModule({\n imports: [\n BrowserModule,\n AgmCoreModule.forRoot({\n apiKey: 'YOUR_KEY'\n })\n ],\nThe Vaadin team has done a lot of the tough work to streamline this process. Their documentation can\nbe found here.
\nAs part of this process, I sent them a PR to\ncorrect their README’s link to these docs.
\nOne of the key changes here is the way that bootstrapping the Web Components polyfill is\naccomplished due to changes to the angular-cli. This includes creating a main-polymer.ts file\nwhich kicks off the bootstrapping of your Angular application after the WebComponentsReady event\nis fired.
\nsrc/main-polymer.ts
\ndocument.addEventListener('WebComponentsReady', () => {\n // Load Angular app\n require('./main.ts');\n});\nThen you need to update angular-cli’s config to use this new main-polymer.ts as your app’s entry point.
\nangular-cli.json
\n\"main\": \"main-polymer.ts\",\nAnother key change from the angular-cli is that loading the webcomponents-lite.min.js file is\nnow easier. I also decided to get it from NPM instead of Bower.
\nangular-cli.json
\n{\n \"scripts\": [\"../node_modules/webcomponents.js/webcomponents-lite.js\"]\n}\nI found that the key here was to require the Basic Web Component scripts in the main-polymer.ts\nfile defined as part of the Angular2-Polymer configuration above. These web components don’t have\ntype definitions for TypeScript and importing their\nES6 modules\nwas a nightmare.
\nsrc/main-polymer.ts
\ndocument.addEventListener('WebComponentsReady', () => {\n // Load basic web components\n require('../node_modules/basic-arrow-selection');\n require('../node_modules/basic-carousel');\n require('../node_modules/basic-page-dots');\n\n // Load Angular app\n require('./main.ts');\n});\nThis worked somewhat, but still resulted in errors since the angular-cli doesn’t have an ES6 loader\nconfigured (separate from the TypeScript loader) and they don’t allow for customization of the\nWebpack configuration. This ES6 still ran OK on the latest Firefox, Chrome, and Safari, but it failed\non IE11.
\nDue to this, I ended up removing Basic Web Components from my project and using\nngBootstrap’s\nCarousel instead.
", "url": "https://devintent.com/blog/2016-10-22-upgrade-from-angular-2-rc4-to-final-with-angular-cli.md", "title": "Upgrade from Angular 2.RC4 to final with Angular-CLI", "summary": "Details about the Angular 2.0.0-rc.5 release.", "date_modified": "2016-10-22T00:00:00.000Z", "tags": [ "angular-cli", "angular" ] }, { "id": "blog/2016-09-14-configuring-an-angularjs-app-for-production.md", "content_html": "When running in production mode, your app should do the following:
\nmyApp.config([\n '$compileProvider',\n '$logProvider',\n function ($compileProvider, $logProvider) {\n $compileProvider.debugInfoEnabled(false);\n $logProvider.debugEnabled(false);\n },\n]);\nNote that this is in addition to whatever else your app needs to do in its .config() function.\nFor this to be fully effective, you should use Angular’s $log service instead of console.log()\nthroughout your app.
As Ben Nadel noted, if your app is doing element.scope() anywhere, it will no longer work after\n$compileProvider.debugInfoEnabled(false) is called.
![\"AngularJS](\"/large-images/angularjs-horizontal-logo.png\"){kind=logo}
It contains 18 breaking changes, over 40 new features, and 80 bug fixes.
\nRC 5 brings with it the significant new ngModule feature along with updates to forms, the router\n(Lazy Loading), material design, and more!
\nThis is the first RC of the new router. You can find out more about the router in Victor Savkin’s\nnew e-book.
\n![\"Angular](\"/icons/angular.svg\"){kind=icon}
The associated Angular team blog post is located here:\nhttp://angularjs.blogspot.com/2016/08/angular-2-rc5-ngmodules-lazy-loading.html
\nThe migration guide used to be found in the Angular 2 docs\nhere but it has been removed.\nIf you need help with upgrading from the RCs, please see\nmy blog post on this topic.
\nThe more detailed Changelog can be reviewed here:\nhttps://github.com/angular/angular/blob/master/CHANGELOG.md#200-rc5-2016-08-09
", "url": "https://devintent.com/blog/2016-08-10-angular-2-rc-5-is-out.md", "title": "Angular 2 rc.5 is out!", "summary": "Details about the Angular 2.0.0-rc.5 release.", "date_modified": "2016-08-10T00:00:00.000Z", "tags": [ "angular" ] }, { "id": "blog/2016-07-15-angularjs-material-1-1-0-rc-x-privatization-of-styles-reverted.md", "content_html": "If you are an AngularJS Material 1.x user, then you might\nhave noticed that, while trying out the 1.1.0 release candidates, many of your CSS fixes and\nworkarounds were broken.
\nYou may have worked around this problem (I know I've spoken to and see many people doing this)\nby changing your styles to target the new \"private\" styles (i.e. the _md-visually-hidden\nclass on md-tabs' md-tabs-dummy-wrapper) introduced in 1.1.0 RC.
![\"The](\"/large-images/angularjs-material-private-styles-example.png\")
I cautioned a number of people against this, pointing out that these are meant to be private\nstyles which will see unannounced breaking changes.
\nUnfortunately, it turns out that these changes were far too disruptive and in some cases there\nwas no work around outside of using the private styles. So these private style changes have\nall been reverted in master via this commit. These changes will be in the next 1.1.0-RC.6\nbuild.
\n![\"Commit](\"/large-images/angularjs-material-private-styles-reverted-commit.png\")
If you have already updated your entire application to rely on these private styles, then\nunfortunately, you will need to revert those changes as well in order to move to the final\n1.1.0 release.
\nNote that this does not remove all private styles. There remain some styles, that existed\nprior to 1.1.0-RC1, that are still preceded with an underscore (\"_\"). These styles remain\nprivate and should not be used as breaking changes to them will not be announced.
\nIf your project is on the latest stable release (1.0.9),\nthen your upgrade path to 1.1.0 should now be a bit smoother when 1.1.0 final lands.
\nAdditionally, if you are trying out Angular Material,\nyou should note that they are planning to include similarly denoted private styles.
\nPlease read this post\nfor additional details and to ask questions.
", "url": "https://devintent.com/blog/2016-07-15-angularjs-material-1-1-0-rc-x-privatization-of-styles-reverted.md", "title": "AngularJS Material 1.1.0-RC.X Privatization of Styles Reverted", "summary": "Discussion of the decision to revert the privatization of styles in AngularJS Material 1.1.0.", "date_modified": "2016-07-15T00:00:00.000Z", "tags": [ "angularjs-material" ] }, { "id": "blog/2016-06-28-responsive-ui-angularjs-material.md", "content_html": "When I presented this material in 2015, the Google Design team was calling it Adaptive UI. It has since been renamed in the\nMaterial Design Specification to\nResponsive UI. Note that, while the phrase uses the word\n\"responsive\", this is different from the Responsive Design from the recent past.
\n\nGoogle defines Responsive UI as:
\n\n\nResponsive layouts in material design adapt to any possible screen size. This UI guidance includes a flexible grid that ensures\n consistency across layouts, breakpoint details about how content reflows on different screens, and a description of how an app can\n scale from small to extra-large screens.
\n
Similar to Responsive Design, the system uses breakpoints which match up with the screen width of various devices.
\n![\"Responsive](\"/large-images/responsive-breakpoints-material-design.png\")
The Material Design site has some great examples of\nthe UI grid. They include animated images to demonstrate how the grid reacts to changes in screen width.
\nFor me, the most interesting and powerful part of Responsive UI with Material Design are the UI Patterns. They demonstrate how to\napply the breakpoints, grid, and surface behaviors to real-world UI design challenges.
\nThese patterns include
\nI've taken some time to update my slides from November to fix some of the broken links and add links to previously unavailable tools.\nOne of these tools, the exciting \"Resizer\", was previewed at the Polymer Summit in 2015.
\nVideo here:
\n\nSince then it has finally been made available for use. Please do check it out!
\nFor more in depth details, discussion, and links, please check out\nthe slides from this\npresentation.
", "url": "https://devintent.com/blog/2016-06-28-responsive-ui-angularjs-material.md", "title": "Responsive UI with AngularJS Material 1.x", "summary": "Responsive UI guidance and tooling for Material Design and AngularJS Material.", "date_modified": "2020-02-03T00:00:00.000Z", "tags": [ "angularjs-material", "angularjs" ] } ] }