Hello, I want to create a onboarding for my app. This is just a single page containing slides. Now this should be just shown, when the user enters the app the first time. For this, I thought I add an item ‘onboarded’ to the localStorage. Now the guard just needs to look if it gets a response when calling this property:
I would just use Ionic Storage instead here, which would eliminate any need for all the manual JSON marshalling, use of the escape function that carries a big “don’t use me” warning, base64 encoding, or anything else that is throwing undesired exceptions.
I would make it part of StorageService's contract that it never throw exceptions.
So If I read the docs to Ionic Storage, I think this is a little ‘overkill’ for my simple Application:
Created for teams building complex, data-driven apps, apps managing sensitive data, …
And in this discussion we are at my main problem again ^^ I always have the problem that some people say I need to that and others say I should do that. For example, some say, I should use Promises whereever I can, others say, I should use Oservebales whenever possible (and then avoid Promises/Observables).
And here’s the same, I saw some tutorails using the system I have and now you tell me that it is crab… And I as a beginner sit here and can flip a coin who is right…
I think you’re referring to something called “Ionic Offline Storage”, with which I have no experience. I’m talking about this. It can use SQLite on device if you wish, or it can just be a frontend for IndexedDB, which works even in ordinary browser environments, making it super-convenient for development.
You have to decide a lot of things for yourself, and one of them is who to pay attention to. Personally, I treat official docs like those from Ionic, Angular, and MDN as the gold standard. There are bloggers (like Ben Lesh, for example) that I trust.
Basically, anything on the internet that tries to sell me “courses” I immediately blacklist. After a while, you develop your own eye for code quality.
I say that Promises are OK for things that are one-shot events, but generally I don’t deploy them in new code unless I’m dealing with an API that provides them. Converting a Promise to an Observable is really easy with the RxJS from operator. Anybody saying you should avoid Observables in a web app (especially an Angular one, where they’re woven deeply into the framework itself) is somebody I would ignore.
The only “tutorials” I would ever pay any attention to when I’m first starting out with a library are the official ones, like the Tour of Heroes. The variation in quality of J. Internet Rando “tutorials” is so great, and my ability to judge what is idiomatic and what isn’t for a framework or library is underdeveloped at that point, so I stick to getting a grounding with official docs.
Okay this seems to be quit easy in usage and does the same as LocalStorage. But still I have a question: Why should a custom StorageEngine be netter than the one provided by Capacitor, which is used to convert web apps into mobile apps?
To me the question would rather be “why did the Capacitor folks make yet another storage system that is harder to use than Ionic Storage, which predates the entire Capacitor project by years?”, and I don’t have a good answer for that.
Do absolutely everything in your power to avoid any
Read this post. In here lies your proximate problem - get is a “class C” function, and so it must be declared to return a Promise (or Observable), and its first word should be return. You have some design leeway for what store and remove are, but need to be aware of the consequences of the choices
So I would write get like this, which should give you an idea of how to fix the rest of StorageService:
I guess so. I would phrase it as improving type safety by avoiding any.
That depends on how you characterize them. In my three-type taxonomy, only the return values from type C functions are relevant. Type A and B functions should return void (as described in that post), because they are designed either so that (A) nobody cares when they finish or (B) they do care internally, but nobody outside needs to know.
I choose never to rely on Storage for in-app communication. You can do so, but if you do, then you must make set return a Promise, and you must religiously wait on every write you make before any code path may potentially read back, or you introduce a race condition whereby a read halfway across your app hits before your last write completed, thanks to one particular router change if the page has been cached on a SamBuzz K-350 phone that has just been rebooted, but only on Thursdays.
Obviously, that example is exaggerated, but race conditions do have a way of not showing up until your app is in production. I have been burned by so many I have lost count.
At first, I wanna thank you for your patience with me! For me this is all really new and it takes me some time to understand everything…
(A) nobody cares when they finish or (B) they do care internally, but nobody outside needs to know.
Since I try to build a little Game it is important to know, if the data sent to the Storage is really stored, which then means I need to declare all Methods to return a Promise and check it then.
And another thing. This <T> stands for declaring a type that is returned, right? I now understood how to use it in my storage-system but I don’t get how to use it in a resolver for example, that should return an array of json-objects: