studio status report: 2018-09

This report is a extremely late as this writing occurs on the last day of the month.

the work on the new SonghaySystem.com continues

The prime suspect for the lateness of this report is the work represented by Songhay.Dashboardissue #16. This single issue got out of control, exploding to 44 comments (all made by me), spanning over 28 days. This issue essentially contains the start of the modern Angular version of the Songhay.Player client (the b-roll player), its curated YouTube Channel experience.

In order to make this experience possible these learnings were discovered (in issue-entry order):

• Angular Module lazy loading
• the active use of Typescript “duck typing” to ‘sketch’ out models without declaring a formal interface
• the Angular @ViewChild pattern replaces most jQuery selector patterns
• Angular’s this.location.replaceState('/not-found') replaces $location.path("/not-found").replace()
• the Angular EventEmitter pattern for data services
• Matias Niemelä and his AnimationBuilder (and the bug with AnimationPlayer [Twitter])
• using SASS maps to generate media queries
• Map should not be used with *ngFor [ref]
• the importance of ChangeDetectionStrategy.OnPush for improving performance [ref]
• using the CSS transform property to scale SVG icons [ref]

major changes to Angular core AppDataService

Currently AppDataService [GitHub] is thrown down next to the Dashboard App source for two mutually exclusive reasons:

• the use of GraphQL has not been adopted (which promises to eliminate all of this code)
• the use of local NPM packages (likely with the songhay-corerepo) has not been exploited

AppDataService was re-factored, adding the loadJson() method [ref] so it can be used like this:

@Injectable()
    export class YouTubePresentationDataServices {
        constructor(client: Http) {
            this.presentationDataService = new AppDataService(client);
            this.videosDataService = new AppDataService(client);
        }

        presentationDataService: AppDataService;

        videosDataService: AppDataService;

        loadPresentation(id): Promise<Response> {
                    const uri = `${YouTubeScalars.rxYouTubeApiRootUri} ${id}`;
                    return this.presentationDataService.loadJson<{}>(uri, json => {});
                }

        loadVideos(id): Promise<Response> {
                    const uri = `${YouTubeScalars.rxYouTubeApiRootUri} ${
                        YouTubeScalars.rxYouTubeApiVideosPath
                    } ${id}`;

        return this.videosDataService.loadJson<{}>(uri, json => {});
        }
    }

What this is saying most importantly is that there is only AppDataService per server call. This will not scale well in more sophisticated Apps, especially where there is no control over the server. The plan is to let GraphQL come to the rescue in near future.

AppDataService has these remaining issues (which should be added to the songhay-corerepo)):

• work in Songhay.Dashboard (including MapObjectUtility.getMap [ref]) should be migrated to songhay-core
• the async-await pattern should be used

One of the promises of GraphQL is the elimination of the need to have real server running in order to build a client. While this promise is deliberately prioritized to be out of my reach for the short term, I need a service running which means I need CORS running.

Got some great help from Edward Thomson from Microsoft to get YAML-based builds working [ref]. This step forward is a significant move toward adding critical automation to the Songhay System.

https://github.com/BryanWilhite/