move `angular.io-index-app` into `songhay-ng-workspace` about songhay-ng-workspace HOT 24 CLOSED

ng generate library @songhay/index --prefix=rx
npm i --save ngx-pagination normalize.css @angular/flex-layout

i see from my note that i may need material-design-icons (with mdi) but i think my later work with SVG will eliminate the need; also, i made no note about why i would need hammerjs

from songhay-ng-workspace.

the BlogEntry model in angular.io-index-app should be ignored as it is already here: https://github.com/BryanWilhite/Songhay.Blog/blob/master/Songhay.Blog/ClientApp/src/app/models/songhay-blog-entry.ts

the Domain conversion pattern of the Songhay observable data store would be used, finally making a coherent resolution for this issue: https://github.com/BryanWilhite/angular.io-index-app/issues/1

from songhay-ng-workspace.

i declared IndexEntriesStore feature complete (028271c) because filterEntries re-factored to use DisplayItemModel is the only feature that should be shared in the Index library

my declaration is based on the assumption that IndexEntriesStore will be provided like this:

{ provide: IndexEntriesStore, useClass: YourClassExtendingIndexEntriesStore }

next move:

ng generate component components/index-container --flat=true --module=index/src/lib/index --project=@songhay/index --skip-tests=false --style=scss --dry-run=true
ng generate component components/index-groups --flat=false --module=index/src/lib/index --project=@songhay/index --skip-tests=false --style=scss --dry-run=true
ng generate component components/index-list --flat=false --module=index/src/lib/index --project=@songhay/index --skip-tests=false --style=scss --dry-run=true
ng generate component components/error --flat=false --module=index/src/lib/index --project=@songhay/index --skip-tests=false --style=scss --dry-run=true

from songhay-ng-workspace.

this last push, 5a6febd, is my first attempt to inject options into a module, following the “NgModule forRoot() Convention”

ah, i incorrectly assumed that forRoot referred to root routes:

By importing the providers at the root, it helps ensure that all lazy-loaded NgModules get the same instance of the provider and is why forRoot() is named as such.

the article referenced above does not make mention of forChild [GitHub] which is in the same source file as forRoot

from songhay-ng-workspace.

weird stuff i did:

-updated these packages to @latest: @angular-devkit/build-ng-packagr, @angular/cli, @angular-devkit/build-angular, @angular/compiler-cli

• added an index/src/assets folder

from songhay-ng-workspace.

index groups issue:

what the red squigglies are really saying is that the legacy code returned an array of object with an itemCategoryObject embedded as ad-hoc JSON with a groupByPropertyName; in the ‘new’ code, this should map to Sortable.itemCategory somehow which implies that a category is being used for grouping

from songhay-ng-workspace.

i added IndexOptions.indexRouterLink to allow lib consumers to link into the content of their domain

from songhay-ng-workspace.

two commits to songhay-core, BryanWilhite/songhay-core@4e89e11 and BryanWilhite/songhay-core@9880894, represent my latest understanding about DisplayItemModel

DisplayItemModel.sortOrdinal and DisplayItemModel.id should be string | number; this composite typing is not possible in C# which is why it has taken me so long to figure this out 👎

commit b70b3b1 is revealing the fact that the only ‘customer’ for IndexEntriesStore is my blog site with its BlogEntry domain type

from songhay-ng-workspace.

last bit on this plate: IndexLibModule

from songhay-ng-workspace.

sort ordinal has been addressed but not topics; the index should derive topics data for topics grouping with formal models

any such client-side metadata might do well in a dictionary on the server side, a general-purpose thing like DisplayItemModel.ClientBag

from songhay-ng-workspace.

trying to inject MockDomainStore with this:

export function provideEntriesStore<TStore extends IndexEntriesStore>(dataStoreType: TStore): {}[] {
    return [{ provide: IndexEntriesStore, useClass: dataStoreType }];
}

from songhay-ng-workspace.

what should be formally addressed (should have its own issue but probably will not 👎 ) is the translation of Index grouping into MenuDisplayItemModel [GitHub]

what also should be recognized in a design document i do not know how write (right now) are Index app topics; the legacy basically crammed a packet of serialized JSON into a semi-arbitrary itemCategoryObject [StackBlitz]

this cramming was basically a sad attempt to associate a loosely-defined object with a formal model; what might be improvement is to bake something with these ingredients:

• a property of Map<string, object> hanging off some interface (Sortable or Groupable?)
• use MenuDisplayItemModel to extend from this interface

from songhay-ng-workspace.

not looking 👀 great:

from songhay-ng-workspace.

next is getting something like this into songhay-core:

const pad = (num: string | number, size: number) => {
    let s = String(num);
    while (s.length < size) {
        s = `0${s}`;
    }
    return s;
};

update: try http://numeraljs.com/ instead

from songhay-ng-workspace.

i see 👀 that the array-map call to generate topic key-value pairs which get turned to into a Map can be generalized into an overload for MapObjectUtility.getMap

from songhay-ng-workspace.

actually an improvement from the last 👀 time:

from songhay-ng-workspace.

this issue will help here: BryanWilhite/songhay-core#9

from songhay-ng-workspace.

IndexGroupingOption needs to be added to IndexOptions; this will allow grouping options to match groups attached to Selectable.map

from songhay-ng-workspace.

this might be the sutra sought for:

from songhay-ng-workspace.

wow 👀:

from songhay-ng-workspace.

for testing:

from songhay-ng-workspace.

ran into this issue: https://flaviocopes.com/how-to-check-undefined-property-javascript/

from songhay-ng-workspace.

getting a bit sleepy

group switching is not working

from songhay-ng-workspace.

better:

okay people 🙄 let’s wrap this up:

• use the old, ancient, old 🥀🧙🏾‍♂️ HTML-comment trick to get [No Grouping] to sort ascending to the bottom
• add a TODO to add support for a custom fallback group other than [No Grouping]
• break out new issues for CSS styling options and routing investigation

it must be mentioned that the legacy Edge browser is painfully slow while trying to group by date (the largest set of groups):

it is much, much faster on Chrome; this HTML parsing hit could come from calling sanitizer.bypassSecurityTrustHtml O(2n) times (from the HTML template instead of code)—which leads me to ask the question, ‘Can I use a framework agnostic version of SafeHtml in songhay-core?’

well, it turns out that SafeHtml is nothing:

the Angular team regards these types as marker interfaces

BTW: this investigation led to another question, ‘How do the other frameworks address the “safe” HTML concept?’ =>

• https://stackoverflow.com/questions/27934238/rendering-raw-html-with-reactjs
• https://alligator.io/vuejs/raw-html-binding/

from songhay-ng-workspace.