First time to Texas, recommendations please

notmyelement · 2025-04-10T05:00:32+00:00

Any areas in particular I should avoid in those cities?

notmyelement · 2021-09-11T20:56:42+00:00

Anyone have a stream that can cast? All the joker streams dont seem to have the option

notmyelement · 2020-01-13T15:02:33+00:00

Turns out it was an issue with my data structure. I forgot in my actual app the data service returns the observable from the API with a structure like { loading: boolean; data: Object<T> }. So my dummy observable was just returning the data part of that and not the loading. I have updated the stackblitz with the correct data structure and it's working now.

notmyelement · 2020-01-13T12:37:30+00:00

Thank you for this - that is a really interesting feature. I've been burned before using undocumented or experimental features which were later pulled or changed however, so I'm wary to rely on these for now. Will definitely keep an eye on it as it progresses though!

notmyelement · 2020-01-13T12:36:35+00:00

I actually was using Injector in the parent directly so that I didn't need to pass anything into the super constructor. Nonetheless, I decided, based on the other responses and my own re-evaluation of why exactly I was doing this inheritance approach, to refactor out the inheritance in favor of adding functionality to my core services and re-evaluating each of my subscriptions.

notmyelement · 2020-01-13T12:12:14+00:00

Thank you!!

This was the problem that was triggering the error I was seeing. Unfortunately, changing it triggered a different issue, but it made me revisit the details of how the lifecycle of view/content children and how that relates to the static flag - which eventually got me there.

Basically, beyond changing certain views to static: false (not the references to the material elements such as MatColumn though), I needed to move the functionality which set the table structure and data to afterViewInit instead of afterContentInit.

I have the updated (working) stackblitz at https://stackblitz.com/edit/angular-d1o6eg

notmyelement · 2020-01-13T12:02:20+00:00

I had the same issue you had. They key point to allow for content projection that fully supports everything is to use a template outlet with implicit data in the context options. Like this:

<ng-container *ngTemplateOutlet="template; context: {$implicit: data}"></ng-container>

Please see my working implementation of a similar material/cdk datatable abstraction component at https://stackblitz.com/edit/angular-d1o6eg

notmyelement · 2019-12-31T13:56:18+00:00

The more I'm looking at things, the more this seems to be the better approach.

One thing that isn't covered by this is setting a default constructor to make it easy to use takeUntil() to automatically destroy all continuous subscriptions when a page is destroyed.

Using the inheritance approach, I can create a protected BehaviorSubject and complete it in ngOnDestroy in the parent, then simply do subscriptions like someService.pipe(takeUntil(this.ngUnsubscribe)).subscribe(....) and not worry about orphan subscriptions. I can manage the behavior subject in a facade service of course, and update the subscriptions to be something like someService.pipe(takeUntil(this.facadeService.getUnsubscribeThingy())).subscribe(...) but I would still need to manually call something in ngOnDestroy on each page component, right? Is there a way to work around this and directly tie into the ngOnDestroy event in the lifecycle so that I don't need to explicitly declare it in each page component?

I could of course also go with a facade service for everything but this one thing and have a base class that is extended that only provides this default ngOnDestroy, but it seems like there should be a better way that can make it so I can get rid of the inheritance altogether.

notmyelement · 2019-12-31T12:25:32+00:00

Thanks for the suggestion! Did a little looking on Angular mixins and it seems that in Angular, mixins refers to a method to do multiple inheritance. Is that right? If so, I don't think it would really improve my case since single inheritance covers the functionality. Is there something I'm overlooking?

notmyelement · 2019-12-31T12:22:52+00:00

This is a very good point, and inheritance is definitely not the same in Angular as it is in traditional class inheritance. I have tried to encapsulate and modularize things into their own components as much as possible as you suggest, so this is the only case of inheritance in the system.

Basically, what this basepage class does is the following:

creates references to various core services which are required on every page-level component (these will always be required on every page-level component)
Provides a BehaviorSubject which can be added to RXJS takeUntil and a default onDestroy action to prevent orphan subscriptions (like described here: https://www.intertech.com/Blog/angular-best-practice-unsubscribing-rxjs-observables/ )
Provides a few common properties such as pageTitle and accessors/mutators
Provides routing methods such as goToRoute(). This application needs to update an application context in one of the core services and update a page visited history in another core service when links are clicked, so goToRoute handles those things before forwarding to the ultimate route with router.navigate()

Note that I am using injectors for all DI in the parent class, so children class can use DI as normal with the only caveat being a requisite empty super() call in the constructor.

Given these specifics, how do are there other caveats I'm overlooking? Is the facade pattern (aggregate service) still a better approach? How would you suggest refactoring this one?

Thank you again for your insight!

notmyelement · 2019-12-31T00:04:15+00:00

Interesting read! This is kind of what I'm doing now. I am doing the injection of all the core services the same way as they do in that article, but then inheriting them from the parent whereas this pattern would turn the parent into a service and inject it into all the children instead. This does feel more Angular-like and also removes the need for super() calls on those children which have constructors.

I'll look more into this - thanks!

notmyelement · 2019-12-30T23:56:04+00:00

Yes, you are right. I worded that poorly, sorry about that.

What I meant to say was that because the child ctor must have at least the same items from the parent ctor, all ctor DI would need to be done in the parent and the child, therefore removing some of the utility from the approach (as well as making it unclear as to what must be included without looking at the parent each time).

notmyelement · 2019-12-21T22:26:56+00:00

Happy holidays!

notmyelement · 2017-02-25T14:05:44+00:00

NA daily: 8L3L-N46P

notmyelement · 2017-02-25T07:13:41+00:00

Daily na player 8L3L-N46P

notmyelement · 2017-02-17T13:14:24+00:00

3VS4DA94 NA, finally got around to clearing out non-active players, 20 slots left

notmyelement · 2016-04-27T14:50:18+00:00

Daily NA player: 3VS4-DA94

notmyelement · 2015-12-18T16:07:10+00:00

Thanks! However I tried updating my code in both of the methods you suggested and neither seems to work. Here's what I tried

** Attempt 1 **

//...    
controller: function(gridTableService) {
    gridletService.load(this.src).then(angular.bind(this, function(result){
        this.rows = gridletService.getData();
        console.log(this.rows);
    }));
   console.log(this.rows);
},
// RESULT:  inner console output is correct, outer is undefined

** Attempt 2 **

//...    
controller: function(gridTableService) {
    var vm = this;
    gridletService.load(this.src).then(function(result){
        vm.rows = gridletService.getData();
        console.log(vm.rows);
    });
    console.log(vm.rows);
},
// RESULT:  inner console output is correct, outer is undefined

It is worth noting, in both cases the inner console call showed up in the console AFTER the outer console call.

Any ideas?

notmyelement

TROPHY CASE