Finally made a breakthrough passing data to a component - felt I should share

First I would like to say how I appreciate this forum, and the support crew who are so helpful in answering so many small questions. I tend not to write much - but I spent many hours on so many days searching for the answer to the many questions that naturally arise while programming.

I am a long time programmer - started back in 1974! - but I only started programming ionic/angular four months ago - so I consider myself a skilled newbie. I’m working on a project, and mostly have made good progress, but I find programming in Ionic/Angular very frustrating! The main frustration seems to come from things that an instructor in a course says will work not working. An example of that is the topic of this post “Passing data to a component via html”

I needed to figure this out - and several months ago I spent more than a week trying everything, without success. I finally figured out how to use a service as an exchange - so a component could “ask” what data it was to use by calling the service which the parent had nicely loaded up with data. I consider this a kludge.

Today, finally! I figured out a method that worked - which is what I felt I should share.

In html I had tried to pass data to the child using [myID]=“item.id.”

Then, as everyone said to do - I used @Input(‘myID’) to bind a component variable to that ID.

I only saw the ID as “undefined” which made me crazy.

Then, today, I saw someone in a forum (stack overflow…) make a slight comment:

“use ngAfterContentInit to get the data - not ngOnInit”

This was what I needed to see - the data is undefined in ngOnInit - but is valid in ngAfterContentInit!

So frustrating that I spent weeks struggling with this - finally writing a kludge work around - but now it works, thanks to some wise soul writing in a random post in a random forum.

Just thought I would share.

thanks for your time - and thanks to all those who are so helpful to all who struggle.

I’d like to take a stab at convincing you that this is much more powerful and much less shameful than it apparently appears to you at the moment.

You’ve got me beat in terms of programming experience, but only by a couple years or so, so I am also very steeped in decades of imperative thinking, and the way you describe the component “asking” the service something is very telling.

Trying to write webapps with an imperative mindset was for me a very frustrating experience. It always felt like I was fighting the framework. I found ReactiveX a confusing katamari of obscure tools, most of which seemed of at best academic interest, so I glommed onto a couple of them, made recipes, and deployed those religiously.

At some point, I decided this was not working at all, and that I had to fundamentally change the way I was thinking about things. Webapps are fundamentally reactive programs - they sit there, wait for users to interact with them, and respond to that interaction. That’s super-hard to debug at first, because I the programmer am no longer in charge of the code execution paths. I had to let that go, and trust that functional thinking could help me isolate parts of my app from one another, enabling them to be viewed and tested as distinct entities.

So, while there’s absolutely nothing wrong with what you’re doing with @Input bindings, realize that it has fundamental limitations as long as you’re slinging scalars around, and that much of Angular’s power comes from its ability to wire Observables up.

With that introduction, when you get a chance, please check out this post for a reactive strategy that automatically delivers fresh data to components exactly when they need it, and only then.

Incidentally, if you’re still reading, I would suggest using ngOnChanges instead of ngAfterContentInit for similar reasons - you have the same guarantee that the data is fresh, and you won’t miss updates that ngAfterContentInit would.

Hi - I didn’t name you, but you were the main person I consider so helpful. I see how many posts you make, trying to help people.

I have switched over to ngOnChange -> thanks. I have tried to hold the lifecycle in my head - but I obviously miss a lot.

I have come to depend on observables to make sense of this asynchronous world. That is one of my go-to tools - although I do worry about unsubscribing in all the right places.

I am happy with using services - I would guess 40% of my code is in services - although I’ve not counted lines. My problems I wanted to solve today was I had a long list of items to display, each one of them being displayed using a component to do the html - so I needed a stateless way to deterministically get my data - and passing the ID via html->Input() seemed the only way.

Yes, the mindset to do this type of programming is interesting - but what bothers me is that the sands shift - even in the 5-6 months I’ve been doing this - an instructor presents code that no longer works. I can adjust my way of thinking, but I often find I implement work-arounds for something that should have worked, but didn’t.

I admire your philosophy and your way of helping people - it’s very admirable.

I use and recommend @ngneat/until-destroy for this.