Something like:

let foo = 0;

is already a number variable, it is implicit due to initialization.

Should we rely on that or should we:

let foo:number = 0;

Let's do an accordion too.

Recreate BS3 Scrollspy with ng2 component.

So we have our @Input and @Output. What should we do on their positioning?

@Input()
set foo(...) {}

Or:

@Input() set foo(...) {}

A good way would be:

If it is a simple variable, inline:

@Input() foo: number;

For a setter we put it on top:

@Input()
set foo(...) {}

So, there is a new kind of panel called Card.

An example would be http://plnkr.co/edit/eaGaEpds72KQlL0YrgRO?p=preview

I don't think we should create a component for this, but potentially update the templates to use cards where it makes sense.

The downside is that we lose the possibility to reuse those templates for bootstrap 3.x

Thoughts?

Could we discuss a slightly different organization of our folders? My main motivation here is to have files that change together go together. In this spirit I would propose (an example for one component):

src
    rating
        rating.ts        
        rating.spec.ts
    core.ts

How does it sound?

I would like to kick-off the discussion on the various API styles we can offer for tooltip / popover / modal users. We need to put a bit of thinking into it a with Angular2 one can't simply say "here is a URL of a template, load me this here". We've got view boundaries and the only things we can insert are:

• templates (things wrapped in the template tag)
• components

Actually the same limitations apply to the Angular 2 router.

Now, as of today I can think of the 3 different styles of API (at this point I'm not even sure if all of them are implementable):

Named TemplateRef

<template #foo>
    Some <b>fancy</b> content
</template>
<div [ngb-tooltip]="foo">

Embedded TemplateRef

<div [ngb-tooltip]="foo">
    <template #foo>
        Some <b>fancy</b> content
    </template>
</div>

ComponentRef

Assuming that Foo is a component:

<div [ngb-tooltip]="Foo">

This issue is to keep track of our over all work and progress towards providing angular 2 components for the core bootstrap 4 javascript components.

• Accordion #17
• Alert #2
• Buttons #14
• Carousel #12
• Collapse #11
• Datepicker #20
• Dropdown #4
• Modal #3
• Pagination #22
• Popover #9
• Progressbar #25
• Rating #26
• ScrollSpy #5
• Tab #7
• Timepicker #24
• Tooltip #8
• Typeahead #21

Implement rating component from UI Bootstrap

This component should ultimately be flexible enough to accept different classes to be bound to the star, similarly as possible in UI Bootstrap now.

I saw that the angular repo is using TSLINT for linting.

We have clang, but clang is not a linter. Stuff like semicolons are not being processed by clang.

To add this, I would need, yet again, reestructure the tooling so linting can be run on the build, travis...

WDYT?

Should we define our component variable as private?

class Foo {
  foo;
  bar;
}

Or

class Foo {
  private foo;
  private bar;
}

This doesn't include private functions when we know that they are not mean to be used in public like helper functions.

Recreate BS3 Tooltip with ng2 component.

An issue to remind myself all the things I need to add here yet

• Readme
• Contributors guide

A clean & simpler datepicker

Recreate BS4 modal with ng2 component.

Call me a romantic, but I had an idea (I put in practice in rating).

I decided to put all my aria related tests in a concrete describe instead of mixing it with other tests.

That way we can see easily everything we done regarding aria in one place. Imo it is better than having to read test by test to see if we do some aria assertion in there.

So what do you think? You like my idea of a big describe (inside UI logic) for all aria related tests and leave the other tests without touching aria or just test the aria stuff when it makes sense in the other tests.

AKA rating tests vs collapse tests.

Yay, first real issue.

The dropdown as is as we have it now (even with pawel changes on toggle) is not working right on the CSS.

Check this plunker

First two works good, the third one doesnt.

There seems to be a dropdown and button dropdown. First two are button dropdown (they need a btn-group) and the third one which is the raw one (the one we support directly) has the popup weirdly.

So talking with @robwormald, we brainstormed some ideas so I ended with the idea of:

We have an interface with all the methods that an Engine should have. For example IDatepickerEngine (not sure if the "I" convention is for us, but for the sake of the demo).

Problem with the interface is that you're not actually forcing the users to use it, but more as a convention so it won't blow up. So not that of a big deal.

Then we create a default engine with a sensible name (more on this later) DatepickerEngine using JS raw implementation.

Then the idea is to offer a constant like NGB_DIRECTIVES but for providers called NGB_BINDINGS. There we register all our providers in application bootstrap (like HTTP does). Downside is that if the user don't use it, app won't work, but I think that is a convention in angular 2.

So now, having an interface, default engine and having it registered with the app at bootstrap, our datepicker will use our implementation.

A end user can create his own engine and register it like:

providers: [provide(DatepickerEngine, {useClass: MyCustomDatepickerEngine})]

Then the datepicker in that component (and children) will use that custom engine now. Downside is that you need to import the original DatepickerEngine to swap it. Not a big deal either.

Check this plunker.

Thoughts?

Creating the issue to capture refactorings / changes needed so that we can migrate to @ContentChildren usage (in favor of now depreciated @Query).

Previous attempts to use @ContentChildren wasn't that great as we were going into race conditions. I've got an alternative proposal which:

• doesn't have race condition pbs (or at least I couldn't "break it")
• makes it possible to use panels as stand-alone as well as part of the accordion

Obviously this implementation isn't ideal as we still need better support in the framework for listening to events from children (see: https://docs.google.com/document/d/1335H9D92jo2Xo0g26BhB_nhrNpCTmHsnRr7t50ndH1Y/edit?usp=sharing)

@Foxandxss / anyone interested: could you please have a look at the implementation proposal, before I jump into full-blown impl, tests changing etc.: http://plnkr.co/edit/PZne4mwc0EsGA2Go0JzH?p=preview

A very common markup in Angular version of bootstrap directives goes like this: <a (click)="prev()">Previous</a>

Pure bootstrap version would have an "empty" href (<a (click)="prev()" href="#">Previous</a>) to provide appropriate styling (cursor) but this is not needed in ng-version and can interfere with routing.

The question: how do we deal with this situation? Few ideas:

• pass $event and call preventDefault() on it; this is what we do in the accordion, for example: https://github.com/ng-bootstrap/core/blob/1d912de06578aca1eaea9ad69942978090da43ff/src/accordion/accordion.ts#L42
• remove href altogether and add cursor styling through CSS (this would be quite easy with ng2 since we've got styles encapsulation)
• try to convince bootstrap folks to "fix it" <- not even sure it makes sense

Now, I must admit that I don't know what is the impact of removing href on accessibility and keyboard navigation, so the encapsulated CSS path might be a non-option in the end...

Thoughts?

Since beta 2/3 jasmine typings are not included so we need to manually load it.

Official recommendation is to use typings, but the problem is that we need to add a /// reference tag thingy in a file that is loaded in our test, AKA a source file or test file.

We just need to add it once, but where? Perhaps core.ts? Were we add a reference to the whole main.d.ts generated by typings?

Another solution is tsconfig.json but I don't think we can do it without having a files array and listing all files there is a real pain.

I could hijack something with gulp but then the IDE won't see it and will raise errors.

I will implement the idea that we get after I can update to a new beta.

Implement timepicker from UI Bootstrap

Should note, this likely will need to be coordinated with the datepicker with the implementation of a default parsing service that can be optionally included that uses the Date constructor.

This should be flexible enough to accept other parsing mechanisms, i.e. moment.js, as long as a common interface is implemented.

A clean & simpler typeahead

Should we prepend variables like:

class Foo {
  _foo;
  _bar;
}

The way to work with components is to create a setter for inputs, that way we can keep or component updated with changes, for example:

@input
set foo(value) {
  this._foo = value;
  // do something
}

So far so good, but you can use this like:

<foo #foo></foo>
{{foo._foo}}

So if we decide to go with underscores, we will have that syntax, our we could create a getter.

If one need to modify/add components, How to test them locally on browser to see whats happening on the UI and for interaction? Currently it's on tests.
We are not pulling bootstrap css locally, then how can we verify the widgets look and feel
Do you plan to support Bootstrap4 or Bootstrap3. Plunker examples are shown for bootstrap3 however issue #1 is being tracked for Bootstrap4

Final Decision: Follow the snippet on this message.

A component can be tested in two ways (and we should do both).

You can test the behavior like we used to test directive's controllers. No UI involved. For example testing that setting a new value on a progressbar, triggers the logic to calculate the new completion percentage.

You can also test UI, that involves the component creation. Same as testing directives as we used to in ui-bootstrap. Following the previous example. We can test that changing the value, the progressbar width changed with the new value.

For this, I propose:

describe('componentname', () => {
  // some common code / matchers / initialization

  describe('business logic', () => {
  });

  describe('UI', () => {
  });
});

Implement progressbar from UI Bootstrap/Bootstrap 3

It is missing (will update this if I get more in mind):

• Animation
• Calculation corner cases
• Aria support.
• Multi bars (if supported).

We start to have different approaches to @Directive selectors: compare accordion that uses both element and attribute vs. dropdown that uses element for something that could be an attribute.

Recreate BS3 Carousel with ng2 Component.

We should support 2 additional options:

• max number of pages displayed
• ellipsis if max no of displayed pages is exceeded

Documentation system and site needs to be built.

It needs to support

• Custom Plunker templates (like currently done on the UI Bootstrap homepage)
• API documentation of each component
• Examples of each component

Replicate BS3 Alert Component

When we create var for collapse like <div ngb-collapse #myCollapse> and try to accesss values like {{myCollapse.collapsed}}, then it gives error Cannot access collapsed of undefined

Recreate BS3 Collapse with ng2 component

Rating is in, but it still needs:

• Custom icons
• Custom titles

We need testing, probably karma with TS tests. Mostly what angular does for their project.

For now, it can test against the final build.

I don't want to have each to be different, so I have some points to discuss.

I recently saw egghead videos, and I found an interesting pattern, you can do something like:

<my-dir #my-dir></my-dir>
{{myDir.someinnerstuff}}

That strikes me a bit, you know, encapsulation and not letting inner details to be usable from outside, but I am not sure if this is going to be a common pattern in Angular so we should allow this. Well, I don't think we have a choice, but this drives me to the next point.

Inner variables on our component, underscored or not?

_foo: string;

vs:

foo: string;

I can see the first pattern, but if allowing it from outside will be common, perhaps that is a weird pattern, or perhaps not (like saying, sure, use it but you shouldn't.

Another point is:

foo = 0;

Typescript will type it as a number automagically (because you initialize it). Should we put number nonetheless?

When to use private? For example of the pagination directive, we have private on a underscore method but not in the variables. For what I see on the wild, they don't use private that much, so I am not sure what to say about this.

Apart from components, we need to host tests files and perhaps documentation as well.

So what is the idea you have? Same directory as we had before? A folder for component + folder for tests + folder for docs and demo

> $ npm run test:ci

> [email protected] test:ci /home/pk/work/gitrepos/gh/pkozlowski-opensource/core
> tsc && karma start --single-run --reporters dots --browsers Firefox

03 11 2015 11:58:34.878:INFO [karma]: Karma v0.13.15 server started at http://localhost:9876/
03 11 2015 11:58:34.884:INFO [launcher]: Starting browser Firefox
03 11 2015 11:58:36.648:INFO [Firefox 41.0.0 (Ubuntu 0.0.0)]: Connected on socket 774nVvYu_cPZdCVlAAAA with id 61003254
03 11 2015 11:58:37.183:WARN [web-server]: 404: /base/node_modules/angular2/angular2.d
Firefox 41.0.0 (Ubuntu 0.0.0) ERROR
  error@/home/pk/work/gitrepos/gh/pkozlowski-opensource/core/node_modules/systemjs/dist/system.src.js:1020:16
  bootstrap/</fetchTextFromURL/xhr.onreadystatechange@/home/pk/work/gitrepos/gh/pkozlowski-opensource/core/node_modules/systemjs/dist/system.src.js:1028:13
  run@/home/pk/work/gitrepos/gh/pkozlowski-opensource/core/node_modules/angular2/bundles/angular2.js:120:14
  zoneBoundFn@/home/pk/work/gitrepos/gh/pkozlowski-opensource/core/node_modules/angular2/bundles/angular2.js:93:14

I will work on tracking it down, but opening since maybe it rings a bell to someone

I'm very much used to 2 testing workflows where I've got 2 separate commands (gulp or whatever):

• gulp tdd - do whatever compilation / preparation, start Karma in watch mode. Re-compile code /tests on each change and re-run Karma tests
• gulp test - do whatever compilation / preparation, start Karma in single-run mode and exit

After quick look at the current gulp file I don't see commands corresponding to those 2 workflows.

How do you guys work on tests? What is your workflow? Do we need to add / change anything in our build?

The accordion is missing:

• All the accessibility
• Be able to use HTML on the header.
• Swap hidden for collapse.
• Use ContentChildren instead of Query.
• Remove circular deps
• See if it is feasible to create a generic panel from the groups.
• Change API of isOpen.

So I am in the need of having a external file for helpers. @wesleycho created a hasClass which is useful for example on rating where I am using classList (which is not IE9 compatible).

The thing is... how?

If I create it for example in misc/test-lib/functions.ts I have to do in rating.spec.ts:

import {hasClass} from '../../misc/test-lib/functions

IDE agrees on that, but after it gets transpiled into .js, it is not going to work anymore (the CJS will try to require a .ts file).

So... transpile it? At first I thought about transpiling all of that into temp/, but the problem is that the paths will change from the original spec.ts file and the one that gets into temp.

So if I have to do:

import {hasClass} from '../../misc/test-lib/functions

In the temp folder I would need to require it from ../../functions.js or ../../test-lib/functions.js. In both options, path changes from original to transpiled.

I could leave helpers in plain javascript and tune karma to pick them. By coincidence, the path won't change in this case, because both original test files and transpiled one are two folder deep so it will always be ../../misc/test-lib/functions.js ...

Problem with that is that typescript is gonna need definition files or perhaps simply complain...

What to do... What to do... Thoughts?

Recreate BS3 Popover with ng2 component.

recreate BS3 drop down with ng2 component.

Recreate BS3 Tab with ng2 component

Evaluate the need for an ng2 component for BS3 buttons.

Recreate BS3 Affix with ng2 component.

We should check what angular does with clang and replicate it.