Synchronization between different components


#1

It’s not a technical question, more like code design question.

In Ionic code there are a lot of asynchronous functions that return promises and observables. But in some cases there is a need to call these functions in synchronous manner and synchronization have to happen between different components in your app.

For such cases I usually use events to synchronize . But I was wondering whether this is the most effective way and if there another way to do it.

Would love to hear your opinion.

Thanks.


#2

I disagree with this assertion. I would consider that a design flaw.


#3

I can only see that arising as a need if you have a critical section – an area of your code where two threads are competing for the same shared resource that can only accommodate one thread at a time. And if you have a critical section, you’re probably doing low-level native programming, so Ionic isn’t the right tool for the job. If you’re flying high enough that you’re using Angular and Ionic, then everything is asynchronous. My advice: Design pages that work because they eventually receive their data, not pages that need data ahead of time or else they crash.


#4

To expand on what @AaronSterling said, you can’t test a component in isolation if part of its functionality is dependent on what is going on in other components. Anything that needs to be shared amongst components should be abstracted into a service.


#5

In fact, many people use providers (services) for that. I’m not yet at that level. Some talk about redux, or injectable providers. It seems to be both ways of doing concurrent recordings.
I’d say a good combination of FormBuilder validators and custom ones, and (ngSubmit) are not too bad.

Regards,


#6

I probably wasn’t very clear when I asked my question. I’m not talking about pages here, or not just about pages. What happens if you need to synchronize between providers?

Here is an example:

I have a provider that initializes connection to back-end server. I have a couple of other providers that retrieve data from this back-end server and do whatever modifications they need to do with this data. Up until now the DB connection string was kind of hard coded and it wasn’t a problem: since I inject the initialization provider into the others, the DB connection has been initialized before the real data retrieval.

Now I need to make this initialization string dynamic, for example read it from a
file. The function that reads from a file returns promise immediately and then the provider that retrieves data is trying to connect to the DB before the connection has been initialized, and fails. In this case, how can I make sure that the connection has been initialized before the actual data retrieval happens?

And no, I can’t put initialization and retrieval code in the same provider. I access many different objects in the DB and I need the initialization to be made only once. And I can’t put code that deals with different DB objects in one provider because it makes code messy and unreadable.

What am I missing? I don’t come from a web development/Angular background, so I really have a feeling that I’m missing something on the conceptual level.

Appreciate your help.

Thanks.


#7

I think you’re thinking imperatively - “how do I make actions X, Y, and Z happen in the order I want them to?”. In web applications, you have to think reactively - “when X happens, I want to Y and Z”.

So you have a service that is in charge of providing this initialization string. It exposes a future that other providers can wait on before doing whatever depends on it. This post has an example of an idiom I use for such situations.


#8

Hi again skydive,

This might be a totally dumb idea, but tell me if I’m wrong at each of these points:

  1. your users use several auth providers
  2. each provider use hard-coded strings for api and each user id
  3. you wanna prevent a test of connection before there is an actual http call, rest api, or whatever call (on what conditions?) - Then a concept would be to pre-record the state before a web request.

The dumb ideas:

  1. why not create a temp database of all that mess in json that will create a huge cache? (preferably on something very fast in DB like mango, or why not Firebase)

  2. using a mix of local storage and this temp database (like deleted every night), to save/cut on requests?

  3. I’m not familiar with it, but Firebase use something called transactions, to prevent “collisions” with requests that have no direct relationship but can all call to the same record at a given time. I’m quite sure you can reproduce or find a way to emulate this behavior with any language like Ruby, plugged to a good (index,key) database, no?

  4. If you record to Mango an additional state key with each record (like key, value, status) i think this is also a valid option to check, and finally you create a promise or observable in TypeScript, that will check on a prebuilt cache of clients (according to their Auth http origin, and that can modify it if any changes), but again I’m totally newbie with that.

Hope it helps,


#9

The notion of subscribing to an Observable. Your initialization code has a public method authStream(): Observable<UserCredential> that emits null when the user is not authenticated, and emits a user credential when the user authenticates. (So maybe UserCredential is really string or boolean, whatever you need.) Your data retrieval profile listens to that, and begins retrieval once authStream() transitions from null to not-null.


#10

@rapropos, thanks for your reply. I liked your idiom. I couldn’t use it exactly like in your example, but it helped me to solve my problem.


#11

And thanks everybody else who tried to help.:slight_smile: