Efficient client-side storage for Angular: simple API + performance + Observables + validation
Fix schematic for "ng add" for Angular 13.
Just a documentation update.
Supports and requires Angular 13.
For some reasons, Angular 13 supports both RxJS >= 6.5.3 or >= 7.4. It can be difficult for lib authors to support multiple versions at the same time.
So while for now the lib still allows RxJS 6 in its peerDependencies as CI tests seem to be fine, be aware we do not guarantee RxJS 6 support. v13 of the lib is built with RxJS 7, and you should upgrade your app to RxJS >= 7.4 too.
Angular 13 dropped Internet Explorer support, and so this lib too.
Supports and requires Angular 13.
For some reasons, Angular 13 supports both RxJS >= 6.5.3 or >= 7.4. It can be difficult for lib authors to support multiple versions at the same time.
So while for now the lib still allows RxJS 6 in its peerDependencies as CI tests seem to be fine, be aware we do not guarantee RxJS 6 support. v13 of the lib is built with RxJS 7, and you should upgrade your app to RxJS >= 7.4 too.
Angular 13 dropped Internet Explorer support, and so this lib too.
Allow RxJS 7 in peerDependencies, to align with Angular 12.2.
Note that Angular and this lib are still built with RxJS 6, so while the tests with RxJS 7 seem to pass, be cautious if you want to upgrade RxJS right now without waiting for Angular 13.
While it may still work, Angular 9 LTS has ended, so it's not officially supported anymore.
ng update @ngx-pwa/local-storage
A full migration guide to version 12 is available.
If you did not update to version 9 yet, be sure to follow the migration guide, as otherwise you could lose all previously stored data.
Supports and requires Angular 12.
Incorrect typings that were deprecated in v11 for .get() and .watch() are now removed:
this.storage.get<User>('user') (add a JSON schema or remove the cast)this.storage.get('user', { type: 'object' }) (cast is required in addition to the JSON schema for non-primitive types)this.storage.get<number>('name', { type: 'string' }) (and all other primitive mismatches)See the migration guide for v11 for detailed instructions.
Angular 2-8 internal engine was named ViewEngine. It was replaced automatically by a new engine called Ivy in Angular 9.
While Angular 9-11 still allowed to manually switch back to ViewEngine, Angular 12 has removed ViewEngine support. So now libraries are compiled directly for Ivy.
Angular 12 deprecates IE 11 support. Meaning it's still supported, but it will be removed in version 13.
No lib change, just rebuilt with Angular 11.1 (still compatible with Angular 11.0).
No lib change, just a fix in schematics to avoid ng add breaking with Angular 11.1.
No change, just a release to update link to new main branch.
A full migration guide to version 11 is available.
If you did not update to version 9 yet, be sure to follow it, as otherwise you could lose all previously stored data.
Supports and requires Angular 11.
TypeScript typings for .get() and .watch() has been modified to better match the library behavior.
For now, wrong usages are just marked as deprecated, so there is no breaking change and it will just be reported by linters. But they may be removed in future releases.
Be sure to read the validation guide for all the why and how of validation.
this.storage.get<User>('user');
was allowed but the result was still unknown.
This is a very common misconception of client-side storage: you can store and get anything in storage, so many people think that casting as above is enough to get the right result type. It's not.
Why? Because you're getting data from client-side storage: so it may have been modified (just go to your browser developer tools and hack what you want).
A cast is just an information for compilation: it basically says to TypeScript: "believe me, it will be a User". But that's not true: you're not sure you'll get a User.
This is why this library provides a runtime validation system, via a JSON schema as the second parameter:
this.storage.get<User>('user', {
type: 'object',
properties: {
name: { type: 'string' },
},
required: ['name'],
});
this.storage.get('user', {
type: 'object',
properties: {
name: { type: 'string' },
},
required: ['name'],
});
was allowed but the result was still unknown.
This is because, for now, the library is able to infer the return type based on the JSON schema for primitives (string, number, integer, boolean and array of these), but not for more complex structures like objects.
So in this case, both the JSON schema and the cast are required:
this.storage.get<User>('user', {
type: 'object',
properties: {
name: { type: 'string' },
},
required: ['name'],
});
Be aware you are responsible the casted type (User) describes the same structure as the JSON schema. For the same reason, the lib can't check that.
Auto-inferring the type from all JSON schemas is in progress in #463.
this.storage.get<number>('name', { type: 'string' });
was allowed but is of course an error. Now the match between the cast and simple JSON schemas (string, number, integer, boolean and array of these) is checked.
Note that in this scenario, the cast is not needed at all, it will be automatically inferred by the lib, so just do:
this.storage.get('name', { type: 'string' });
as const assertion
Given how JSON schema works, sometimes it's better to set them as const:
this.storage.get('name', { type: 'string' } as const);
But before v11, it was not possible when using some JSON schema properties
(enum, items, required). This is now fixed.