New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta Issue: Roadmap - Q3 #142

Closed
nshahan opened this Issue Aug 10, 2017 · 42 comments

Comments

Projects
None yet
@nshahan
Contributor

nshahan commented Aug 10, 2017

Current Projects - Q3

We schedule our work a quarter at a time. Here is what we are working on right now.

Update the sync process between Github and Google internal repo.

  • Sync faster and more often.
  • Internal commits land as individual commits externally.
  • Provide ability to bring pull requests from Github into Google internal repo.
  • Allows reorganization of Github repo so clients can import without reaching into src directories.

Add SASS compilation to the build step.

Tracking issue #45.

  • CSS is generated during build step from the SASS files.
  • Remove pre-compiled CSS files from the repo.
  • Allow clients to import our SASS mixins in their SASS files.

Add application layout features.

Issue #103

  • Application bar.
  • Side menu drawers.

Continue adding more components to the external repo.

There is an ongoing goal to release more components. Outside of the application layout features these releases don't have a committed timeline. See list below.

Components planned for release

Not a timeline for release, but here are some of the components that we know we would like to add to this repo.

  • Material Auto Suggest Input
  • Material Date Range Picker
  • Material Drawer
  • Material Header
  • Material Menu
  • Material Select Searchbox
@SCKelemen

This comment has been minimized.

Show comment
Hide comment
@SCKelemen

SCKelemen Aug 11, 2017

What is the possibility of getting a DataGrid / Table component/module?

SCKelemen commented Aug 11, 2017

What is the possibility of getting a DataGrid / Table component/module?

@nshahan

This comment has been minimized.

Show comment
Hide comment
@nshahan

nshahan Aug 11, 2017

Contributor

No definite plans for release at the moment.

It is on our radar and we would like to release it but there are substantial dependencies that must be removed/replaced or open sourced first. It is a non-trivial amount of work that is not planned to start this quarter.

We are focusing on getting better support for this repo and the components that have already been released first.

Contributor

nshahan commented Aug 11, 2017

No definite plans for release at the moment.

It is on our radar and we would like to release it but there are substantial dependencies that must be removed/replaced or open sourced first. It is a non-trivial amount of work that is not planned to start this quarter.

We are focusing on getting better support for this repo and the components that have already been released first.

@sureshg

This comment has been minimized.

Show comment
Hide comment
@sureshg

sureshg Aug 28, 2017

Any plans for fixed and sticky footer component? It would be a great addition to layout components.

sureshg commented Aug 28, 2017

Any plans for fixed and sticky footer component? It would be a great addition to layout components.

@nshahan

This comment has been minimized.

Show comment
Hide comment
@nshahan

nshahan Aug 30, 2017

Contributor

@sureshg No plans for those at the moment but it there is significant interest we can evaluate.

Contributor

nshahan commented Aug 30, 2017

@sureshg No plans for those at the moment but it there is significant interest we can evaluate.

@nni123

This comment has been minimized.

Show comment
Hide comment
@nni123

nni123 Sep 10, 2017

any time frame for next release

nni123 commented Sep 10, 2017

any time frame for next release

@TedSander

This comment has been minimized.

Show comment
Hide comment
@TedSander

TedSander Sep 11, 2017

Contributor

@nni123 earliest Friday, but probably next week. Anything you are looking for in particular?

Contributor

TedSander commented Sep 11, 2017

@nni123 earliest Friday, but probably next week. Anything you are looking for in particular?

@SCKelemen

This comment has been minimized.

Show comment
Hide comment
@SCKelemen

SCKelemen Sep 11, 2017

@TedSander @nshahan Is there any hope for a document viewer anytime in the next year?

Also, can you confirm if the new YouTube UI is AngularDart?
I also see 'fast table' made it onto the list (many more, including a fast table). Can you give projected quarter for release? Q2 '18?
And lastly, can you define what a Material Header is?

I'd also like to thank you all for being so responsive.

SCKelemen commented Sep 11, 2017

@TedSander @nshahan Is there any hope for a document viewer anytime in the next year?

Also, can you confirm if the new YouTube UI is AngularDart?
I also see 'fast table' made it onto the list (many more, including a fast table). Can you give projected quarter for release? Q2 '18?
And lastly, can you define what a Material Header is?

I'd also like to thank you all for being so responsive.

@TedSander

This comment has been minimized.

Show comment
Hide comment
@TedSander

TedSander Sep 11, 2017

Contributor

@SCKelemen can you expand on what you mean by a document viewer? Are you talking about API docs? or something else?

YouTube is being written in Polymer: https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtubes-new-look-and.html

Sorry can't give you a date on 'fast table' it has quite a lot of dependencies and is quite complicated making open sourcing it harder. We hope we can see something next year, but I really can't give a date.

Material Header is also known as toolbar, or app bar. MDL and MCW simply use the header html tag, but we wanted to make it look more like a component. So we added the material- prefix.

Contributor

TedSander commented Sep 11, 2017

@SCKelemen can you expand on what you mean by a document viewer? Are you talking about API docs? or something else?

YouTube is being written in Polymer: https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtubes-new-look-and.html

Sorry can't give you a date on 'fast table' it has quite a lot of dependencies and is quite complicated making open sourcing it harder. We hope we can see something next year, but I really can't give a date.

Material Header is also known as toolbar, or app bar. MDL and MCW simply use the header html tag, but we wanted to make it look more like a component. So we added the material- prefix.

@nni123

This comment has been minimized.

Show comment
Hide comment
@nni123

nni123 Sep 12, 2017

@TedSander I am looking at material drawer and date picker components. Thanks for the update.

nni123 commented Sep 12, 2017

@TedSander I am looking at material drawer and date picker components. Thanks for the update.

@TedSander

This comment has been minimized.

Show comment
Hide comment
@TedSander

TedSander Sep 12, 2017

Contributor

@nni123 material drawer was already released. It is in the app_layout directory.

No timeline for any of the datepicker components, all I can say is probably not this year.

Contributor

TedSander commented Sep 12, 2017

@nni123 material drawer was already released. It is in the app_layout directory.

No timeline for any of the datepicker components, all I can say is probably not this year.

@rwrozelle

This comment has been minimized.

Show comment
Hide comment
@rwrozelle

rwrozelle Sep 13, 2017

Sad to hear that about material-date-range-picker, it was on the list from the start and I've avoided building one myself because of that.

rwrozelle commented Sep 13, 2017

Sad to hear that about material-date-range-picker, it was on the list from the start and I've avoided building one myself because of that.

@TedSander

This comment has been minimized.

Show comment
Hide comment
@TedSander

TedSander Sep 13, 2017

Contributor

So good news. I just talked with the leads implementing the widget, and they are mostly past a massive redesign they have been doing in the last year. So there is a good chance we can get the datepicker out this year.

Contributor

TedSander commented Sep 13, 2017

So good news. I just talked with the leads implementing the widget, and they are mostly past a massive redesign they have been doing in the last year. So there is a good chance we can get the datepicker out this year.

@NoahWilcox

This comment has been minimized.

Show comment
Hide comment
@NoahWilcox

NoahWilcox Sep 13, 2017

Hey @TedSander

I came here in hopes of finding a Data Table component, but to no avail. I noticed it was mentioned in the readme section a little bit, but isn't mentioned in the release plan. I saw @SCKelemen made a comment in this issue with a fair amount of people interested in the same feature.

Any chance this is in the works?

NoahWilcox commented Sep 13, 2017

Hey @TedSander

I came here in hopes of finding a Data Table component, but to no avail. I noticed it was mentioned in the readme section a little bit, but isn't mentioned in the release plan. I saw @SCKelemen made a comment in this issue with a fair amount of people interested in the same feature.

Any chance this is in the works?

@TedSander

This comment has been minimized.

Show comment
Hide comment
@TedSander

TedSander Sep 13, 2017

Contributor

@NoahWilcox it is in the works, but it is still early days. It is a lot of work to untangle our internal dependencies, but stay tuned.

Contributor

TedSander commented Sep 13, 2017

@NoahWilcox it is in the works, but it is still early days. It is a lot of work to untangle our internal dependencies, but stay tuned.

@Scorpiion

This comment has been minimized.

Show comment
Hide comment
@Scorpiion

Scorpiion Sep 25, 2017

Is there any recommended/commonly used workaround for a the lack of a table component?

I guess using the JS version might be a bit hard(?), maybe better to try and use the MDL version with some extra logic if/where needed?

Personally I think if would be more important to get a table component out there than to get it super fast and perfect from day one. I would not mind if it was a little slow (relatively speaking and assuming it's fast for small 5-10 row tables) in the beginning and got faster over time.

Scorpiion commented Sep 25, 2017

Is there any recommended/commonly used workaround for a the lack of a table component?

I guess using the JS version might be a bit hard(?), maybe better to try and use the MDL version with some extra logic if/where needed?

Personally I think if would be more important to get a table component out there than to get it super fast and perfect from day one. I would not mind if it was a little slow (relatively speaking and assuming it's fast for small 5-10 row tables) in the beginning and got faster over time.

@TedSander

This comment has been minimized.

Show comment
Hide comment
@TedSander

TedSander Sep 26, 2017

Contributor

For a small 5-10 row table ngFor works in that case and you could use mdl for styling.

The reason we haven't released the table component has nothing to do with speed. The one we have internally is super fast. It isn't released because we can't release all the technology required at this time.

As stated above we are actively working on it.

Contributor

TedSander commented Sep 26, 2017

For a small 5-10 row table ngFor works in that case and you could use mdl for styling.

The reason we haven't released the table component has nothing to do with speed. The one we have internally is super fast. It isn't released because we can't release all the technology required at this time.

As stated above we are actively working on it.

@Scorpiion

This comment has been minimized.

Show comment
Hide comment
@Scorpiion

Scorpiion Sep 26, 2017

Thanks @TedSander, I did not mean to imply that your table is slow. I was a bit naive thinking it would be possible to release a slower version of your fast table.

Looking forward to test the dart native table when it's ready!

Scorpiion commented Sep 26, 2017

Thanks @TedSander, I did not mean to imply that your table is slow. I was a bit naive thinking it would be possible to release a slower version of your fast table.

Looking forward to test the dart native table when it's ready!

@rwrozelle

This comment has been minimized.

Show comment
Hide comment
@rwrozelle

rwrozelle Oct 10, 2017

I've been reviewing the _mixins.scss in each of the components in preparation for the release of SASS capability and I do not understand the naming pattern for mixins. How will this be documented and how will naming integrity be maintained across components? Thanks

rwrozelle commented Oct 10, 2017

I've been reviewing the _mixins.scss in each of the components in preparation for the release of SASS capability and I do not understand the naming pattern for mixins. How will this be documented and how will naming integrity be maintained across components? Thanks

@TedSander

This comment has been minimized.

Show comment
Hide comment
@TedSander

TedSander Oct 10, 2017

Contributor

You are right that there isn't a very clear naming pattern on the mixins. They are largely contributed by the internal community and because of that there hasn't been a lot of consistency. I don't think we will spend a lot of time cleaning that up as we would rather spend efforts elsewhere.

In terms of the documentation we have some ideas for that, but it is still very much in the early stages. Getting the Sass in the repo unblocks a lot of other work so we wanted to get it to the community early rather than hold things back before they were perfect.

Contributor

TedSander commented Oct 10, 2017

You are right that there isn't a very clear naming pattern on the mixins. They are largely contributed by the internal community and because of that there hasn't been a lot of consistency. I don't think we will spend a lot of time cleaning that up as we would rather spend efforts elsewhere.

In terms of the documentation we have some ideas for that, but it is still very much in the early stages. Getting the Sass in the repo unblocks a lot of other work so we wanted to get it to the community early rather than hold things back before they were perfect.

@rwrozelle

This comment has been minimized.

Show comment
Hide comment
@rwrozelle

rwrozelle Oct 14, 2017

Thank you for your response and as they say "Perfect is the enemy of Good" Looking forward to Sass.

rwrozelle commented Oct 14, 2017

Thank you for your response and as they say "Perfect is the enemy of Good" Looking forward to Sass.

@rwrozelle

This comment has been minimized.

Show comment
Hide comment
@rwrozelle

rwrozelle Oct 26, 2017

I am not able to make the angular_components respond to a mixin call. I've converted my top main.css to main.scss, I've added the following:

@import 'package:angular_components/css/material/material';
@import 'package:angular_components/material_input/_mixins';
$primary-color: red;
@include material-input-theme($primary-color);

When I look at the converted main.css I see:

::ng-deep material-input.themeable ::ng-deep .focused-underline {
  background-color: red;
}
::ng-deep material-input.themeable .cursor {
  background-color: red;
}
::ng-deep material-input.themeable .focused.label-text {
  color: red;
}

So I know that sass-builder is working, but I don't see any color changes in my material-inputs. Can you please add an example of using mixins?

rwrozelle commented Oct 26, 2017

I am not able to make the angular_components respond to a mixin call. I've converted my top main.css to main.scss, I've added the following:

@import 'package:angular_components/css/material/material';
@import 'package:angular_components/material_input/_mixins';
$primary-color: red;
@include material-input-theme($primary-color);

When I look at the converted main.css I see:

::ng-deep material-input.themeable ::ng-deep .focused-underline {
  background-color: red;
}
::ng-deep material-input.themeable .cursor {
  background-color: red;
}
::ng-deep material-input.themeable .focused.label-text {
  color: red;
}

So I know that sass-builder is working, but I don't see any color changes in my material-inputs. Can you please add an example of using mixins?

@TedSander

This comment has been minimized.

Show comment
Hide comment
@TedSander

TedSander Oct 26, 2017

Contributor

::ng-deep is rewritten by angular itself. For it to be rewritten it needs to be a part of an angular component.

I would suggest putting main.scss.css as a styleUrl on your root component.

Contributor

TedSander commented Oct 26, 2017

::ng-deep is rewritten by angular itself. For it to be rewritten it needs to be a part of an angular component.

I would suggest putting main.scss.css as a styleUrl on your root component.

@rwrozelle

This comment has been minimized.

Show comment
Hide comment
@rwrozelle

rwrozelle Oct 27, 2017

Thanks, a couple of items:

It took me a while to understand main.scss.css, I finally found this in the angular_components pubspec.yaml

- sass_builder:
    outputExtension: .scss.css

and the lightbulb went on. I believe this an artifact of having both .scss and .css files in the angular_components repository for a number of prior versions and it may be better to remove this in the future to prevent confusion.

I am able to get the mixin to work, but have a fundamental problem. My application heavily uses ComponentLoader.loadNextToLocation. I am providing portal with end-user self-service build out of pages. I've found that the mixin will not work in the component that is using loadNextToLocation. That is to say, the dynamic children do not respect ::ng-deep. Is this a known issue?

rwrozelle commented Oct 27, 2017

Thanks, a couple of items:

It took me a while to understand main.scss.css, I finally found this in the angular_components pubspec.yaml

- sass_builder:
    outputExtension: .scss.css

and the lightbulb went on. I believe this an artifact of having both .scss and .css files in the angular_components repository for a number of prior versions and it may be better to remove this in the future to prevent confusion.

I am able to get the mixin to work, but have a fundamental problem. My application heavily uses ComponentLoader.loadNextToLocation. I am providing portal with end-user self-service build out of pages. I've found that the mixin will not work in the component that is using loadNextToLocation. That is to say, the dynamic children do not respect ::ng-deep. Is this a known issue?

@leonsenft

This comment has been minimized.

Show comment
Hide comment
@leonsenft

leonsenft Oct 27, 2017

Contributor

Hi @rwrozelle, could you please elaborate on the issue with ::ng_deep and loadNextToLocation? What exactly do you mean the dynamic children don't respect ::ng-deep? This would be an issue with Angular itself; would you be willing to file an issue describing your problem please?

https://github.com/dart-lang/angular/issues

Contributor

leonsenft commented Oct 27, 2017

Hi @rwrozelle, could you please elaborate on the issue with ::ng_deep and loadNextToLocation? What exactly do you mean the dynamic children don't respect ::ng-deep? This would be an issue with Angular itself; would you be willing to file an issue describing your problem please?

https://github.com/dart-lang/angular/issues

@rwrozelle

This comment has been minimized.

Show comment
Hide comment
@rwrozelle

rwrozelle Oct 27, 2017

@leonsenft ,
I just figured my problem out. I had my AppComponent set to ViewEncapsulation.None and mistakenly thought my problem was related to using loadNextToLocation.

rwrozelle commented Oct 27, 2017

@leonsenft ,
I just figured my problem out. I had my AppComponent set to ViewEncapsulation.None and mistakenly thought my problem was related to using loadNextToLocation.

@Brahmasmi

This comment has been minimized.

Show comment
Hide comment
@Brahmasmi

Brahmasmi Nov 16, 2017

@nshahan @TedSander would it be possible for us to update/edit the original issue here for Q4?

From what I understand, the Material Drawer component has been released. Could we please add it, and any other released components, to the README.

Thanks.

Brahmasmi commented Nov 16, 2017

@nshahan @TedSander would it be possible for us to update/edit the original issue here for Q4?

From what I understand, the Material Drawer component has been released. Could we please add it, and any other released components, to the README.

Thanks.

@nshahan

This comment has been minimized.

Show comment
Hide comment
@nshahan

nshahan Nov 16, 2017

Contributor

@Brahmasmi Thanks for the ping here. The README should get an update with our next release. I'll summarize what we finished last quarter and I'll open a new road map issue for what we are working on for Q4.

Q3 Work Summary

While releasing new versions to stay up to date with the Angular package releases we did some work behind the scenes to improve this package.

Update the sync process between Github and Google internal repo.

We are now syncing between Google internal repo <--> Github using the new script. This allows:

  • Syncing faster and more often.
  • Internal commits land as individual commits externally.

This technically provides us the ability to bring pull requests from Github into our internal repo and attempt to land them but we are not yet ready begin accepting pull requests. Look for a contributor guide coming soon that will explain how the process will work and what we can accept.

Add SASS compilation to the build step.

We worked with @luisvt on the sass_builder package to support the needed compilation during the build process.

  • CSS is generated during build step from the SASS files.
  • Allow clients to import our SASS mixins in their SASS files.

Continue adding more components to the external repo.

  • Material Select Searchbox
  • Application Layout Components
    • Drawers
    • App Bar
  • Material Auto Suggest Input

Reorganize and cleanup directory structure.

The combination of the new syncing script and compiling CSS during the build allows us to change the structure of the external package.

  • Remove pre-compiled css files.
  • Move individual component entry points out of lib/src to allow selectively importing only the components you need.
Contributor

nshahan commented Nov 16, 2017

@Brahmasmi Thanks for the ping here. The README should get an update with our next release. I'll summarize what we finished last quarter and I'll open a new road map issue for what we are working on for Q4.

Q3 Work Summary

While releasing new versions to stay up to date with the Angular package releases we did some work behind the scenes to improve this package.

Update the sync process between Github and Google internal repo.

We are now syncing between Google internal repo <--> Github using the new script. This allows:

  • Syncing faster and more often.
  • Internal commits land as individual commits externally.

This technically provides us the ability to bring pull requests from Github into our internal repo and attempt to land them but we are not yet ready begin accepting pull requests. Look for a contributor guide coming soon that will explain how the process will work and what we can accept.

Add SASS compilation to the build step.

We worked with @luisvt on the sass_builder package to support the needed compilation during the build process.

  • CSS is generated during build step from the SASS files.
  • Allow clients to import our SASS mixins in their SASS files.

Continue adding more components to the external repo.

  • Material Select Searchbox
  • Application Layout Components
    • Drawers
    • App Bar
  • Material Auto Suggest Input

Reorganize and cleanup directory structure.

The combination of the new syncing script and compiling CSS during the build allows us to change the structure of the external package.

  • Remove pre-compiled css files.
  • Move individual component entry points out of lib/src to allow selectively importing only the components you need.

@nshahan nshahan closed this Nov 16, 2017

@nshahan nshahan changed the title from Meta Issue: Roadmap to Meta Issue: Roadmap - Q3 Nov 16, 2017

@nshahan

This comment has been minimized.

Show comment
Hide comment
@nshahan

nshahan Nov 16, 2017

Contributor

Added a road map for our work in Q4 #193.

Contributor

nshahan commented Nov 16, 2017

Added a road map for our work in Q4 #193.

@Brahmasmi

This comment has been minimized.

Show comment
Hide comment
@Brahmasmi

Brahmasmi commented Nov 16, 2017

Danke @nshahan.

@Brahmasmi

This comment has been minimized.

Show comment
Hide comment
@Brahmasmi

Brahmasmi Nov 16, 2017

@TedSander I just noticed that a lot of requests for components were made in this issue thread. Would it be possible for us to somehow track these requests via issues?

I see the following component requests:

  1. DataTable/DataGrid
  2. DatePicker
  3. Fixed and Sticky footer

Also, may be we can mention in the README the issues which track these components. If there is no issue to track the component, we could request the community to make one and request update of the README. This is just top of the mind thinking. The aim is to not drop the ball and lose context. Otherwise there is a chance that the volks would again request the same components on the new Q4 roadmap, without being aware of the conversation here.

Brahmasmi commented Nov 16, 2017

@TedSander I just noticed that a lot of requests for components were made in this issue thread. Would it be possible for us to somehow track these requests via issues?

I see the following component requests:

  1. DataTable/DataGrid
  2. DatePicker
  3. Fixed and Sticky footer

Also, may be we can mention in the README the issues which track these components. If there is no issue to track the component, we could request the community to make one and request update of the README. This is just top of the mind thinking. The aim is to not drop the ball and lose context. Otherwise there is a chance that the volks would again request the same components on the new Q4 roadmap, without being aware of the conversation here.

@TedSander

This comment has been minimized.

Show comment
Hide comment
@TedSander

TedSander Nov 16, 2017

Contributor

I read all the feedback and comments on here and our other mediums. Stackoverflow, issues, etc. I hope you don't see us as dropping the ball.

The issue tracker is largely for the community. If users want to add separate issues for requests that is fine, but I also can't stop people from giving requests on various mediums (comments, stackoverflow, etc.)

I'd rather have the roadmap be the context for what is happening for the next quarter. We don't plan much beyond a quarter as being in tech our requirements are constantly evolving and changing.

As far as some of your specific requests:
Data Table: There is a good chance it isn't going to live in this repo but will be separate. Even in google our table is a completely different effort because it is that important. I think there is a good chance when we are ready to release it, it will be in a separate repo. So you might not see a lot of updates here on that. Expect further announcements next year.

DatePicker: You should already have seen the update in the roadmap

Fixed and Sticky footer: It isn't really clear that we are going to provide this. Internally it isn't really a priority, and we have a lot on our plate that we want to accomplish. We listen to all feedback, but that doesn't mean that it will get on our roadmap.

Contributor

TedSander commented Nov 16, 2017

I read all the feedback and comments on here and our other mediums. Stackoverflow, issues, etc. I hope you don't see us as dropping the ball.

The issue tracker is largely for the community. If users want to add separate issues for requests that is fine, but I also can't stop people from giving requests on various mediums (comments, stackoverflow, etc.)

I'd rather have the roadmap be the context for what is happening for the next quarter. We don't plan much beyond a quarter as being in tech our requirements are constantly evolving and changing.

As far as some of your specific requests:
Data Table: There is a good chance it isn't going to live in this repo but will be separate. Even in google our table is a completely different effort because it is that important. I think there is a good chance when we are ready to release it, it will be in a separate repo. So you might not see a lot of updates here on that. Expect further announcements next year.

DatePicker: You should already have seen the update in the roadmap

Fixed and Sticky footer: It isn't really clear that we are going to provide this. Internally it isn't really a priority, and we have a lot on our plate that we want to accomplish. We listen to all feedback, but that doesn't mean that it will get on our roadmap.

@Brahmasmi

This comment has been minimized.

Show comment
Hide comment
@Brahmasmi

Brahmasmi Nov 16, 2017

May be I was not clear in my original communication, so let me try again.

I don't think at any point have I said that I see us dropping the ball, rather I said the aim was to not drop it. Preventive action. But may be I was imprecise. Additionally, I do not expect you (or anyone else for that matter) to regulate where volks raise requests. May be I am unaware of how these things work, but I have seen other projects typically put one issue for one feature request, and mark other similar feature requests as dupes. Also, I do not think that filing an issue automatically promotes it to the roadmap or a milestone, and I am not sure anyone expects that.

The broad idea is to provide guidance to the community. Communication helps. Guidance that one could file an issue if one does not see an issue for one's component request. Guidance that please search for your component before filing the issue. The idea is to help prevent repetitive "I want foo", "we are building foo - marking dupe - original issue somenumber" ping-pong. This helps track that feature component - if and when it gets on the roadmap, and to be marked completed once done. SNR.

I am very sure you already know all of the above, but I am listing it down to explain what I intended to convey.

Also, thanks for providing information about those components. Personally, I am not concerned about the status of those components. Those component requests were raised on this issue thread by other folks, and I presume it was largely because it is the roadmap thread. But I may be wrong.

  1. Datetable - requested by @SCKelemen , @NoahWilcox , @Scorpiion
  2. Datepicker - requested by @nni123 , @rwrozelle
  3. Fixed and sticky footer - requested by @sureshg

Brahmasmi commented Nov 16, 2017

May be I was not clear in my original communication, so let me try again.

I don't think at any point have I said that I see us dropping the ball, rather I said the aim was to not drop it. Preventive action. But may be I was imprecise. Additionally, I do not expect you (or anyone else for that matter) to regulate where volks raise requests. May be I am unaware of how these things work, but I have seen other projects typically put one issue for one feature request, and mark other similar feature requests as dupes. Also, I do not think that filing an issue automatically promotes it to the roadmap or a milestone, and I am not sure anyone expects that.

The broad idea is to provide guidance to the community. Communication helps. Guidance that one could file an issue if one does not see an issue for one's component request. Guidance that please search for your component before filing the issue. The idea is to help prevent repetitive "I want foo", "we are building foo - marking dupe - original issue somenumber" ping-pong. This helps track that feature component - if and when it gets on the roadmap, and to be marked completed once done. SNR.

I am very sure you already know all of the above, but I am listing it down to explain what I intended to convey.

Also, thanks for providing information about those components. Personally, I am not concerned about the status of those components. Those component requests were raised on this issue thread by other folks, and I presume it was largely because it is the roadmap thread. But I may be wrong.

  1. Datetable - requested by @SCKelemen , @NoahWilcox , @Scorpiion
  2. Datepicker - requested by @nni123 , @rwrozelle
  3. Fixed and sticky footer - requested by @sureshg
@eduardotd

This comment has been minimized.

Show comment
Hide comment
@eduardotd

eduardotd Nov 20, 2017

It would be great to have a built in grid system...

eduardotd commented Nov 20, 2017

It would be great to have a built in grid system...

@TedSander

This comment has been minimized.

Show comment
Hide comment
@TedSander

TedSander Nov 21, 2017

Contributor

I don't see us providing a grid system as it would just be CSS styles. I suggest looking at https://github.com/material-components/material-components-web/tree/master/packages/mdc-layout-grid

Which is what teams use internally.

Contributor

TedSander commented Nov 21, 2017

I don't see us providing a grid system as it would just be CSS styles. I suggest looking at https://github.com/material-components/material-components-web/tree/master/packages/mdc-layout-grid

Which is what teams use internally.

@eduardotd

This comment has been minimized.

Show comment
Hide comment
@eduardotd

eduardotd Nov 21, 2017

eduardotd commented Nov 21, 2017

@RaduGrama

This comment has been minimized.

Show comment
Hide comment
@RaduGrama

RaduGrama Mar 12, 2018

Regarding the absence of a data table component, is there any suggestion for a third party that would work? It's surprising that this component is missing even in a basic incarnation, and it's a bit of an adoption blocker, especially since material.angular.io has a basic version at https://material.angular.io/components/table/overview.

RaduGrama commented Mar 12, 2018

Regarding the absence of a data table component, is there any suggestion for a third party that would work? It's surprising that this component is missing even in a basic incarnation, and it's a bit of an adoption blocker, especially since material.angular.io has a basic version at https://material.angular.io/components/table/overview.

@nni123

This comment has been minimized.

Show comment
Hide comment
@nni123

nni123 Mar 19, 2018

@RaduGrama same here... ask for it a long time ago and moved on to a different platform since no reliable third-party component as well (File Upload as well but I can work out something)

nni123 commented Mar 19, 2018

@RaduGrama same here... ask for it a long time ago and moved on to a different platform since no reliable third-party component as well (File Upload as well but I can work out something)

@nshahan

This comment has been minimized.

Show comment
Hide comment
@nshahan

nshahan Apr 5, 2018

Contributor

We are aware that there is a need for a good table component and are still working towards releasing a version of ours.

I'm sorry I don't have an alternative pre-made component to offer you. If it is a small amount of data, displaying the rows with ngFor is probably the easiest option.

Contributor

nshahan commented Apr 5, 2018

We are aware that there is a need for a good table component and are still working towards releasing a version of ours.

I'm sorry I don't have an alternative pre-made component to offer you. If it is a small amount of data, displaying the rows with ngFor is probably the easiest option.

@gedw99

This comment has been minimized.

Show comment
Hide comment
@gedw99

gedw99 Jul 5, 2018

This projects delivery expectation management is pretty bad.
It's a shame because a ton of Devs have just been forced to use the MDC web components and the react and vuejs frameworks that use MDC.

It's a shame because of all the work that went into getting the Dart 2.0 web compiler working but hardly anyone is using it because this project has such poor roadmap and expectation management. Its almost passive aggressive but not quite.

I use flutter and the material components and team read back is really quite good.

It read that there is a plan to port the way you code in flutter to dart web. If it's true than say it so people can manage their own roadmaps. I say this because it just feels like the team is hoping for no adoption of dart angular web components so that people are not a using Google of another dropped project after flutter web comes out ( or whatever it will be called ).
Am not going to apologise for saying all these things above because it's pretty clear.
You even have your own PO / PM trying to get some energy / integrity into the way things are managed here.

gedw99 commented Jul 5, 2018

This projects delivery expectation management is pretty bad.
It's a shame because a ton of Devs have just been forced to use the MDC web components and the react and vuejs frameworks that use MDC.

It's a shame because of all the work that went into getting the Dart 2.0 web compiler working but hardly anyone is using it because this project has such poor roadmap and expectation management. Its almost passive aggressive but not quite.

I use flutter and the material components and team read back is really quite good.

It read that there is a plan to port the way you code in flutter to dart web. If it's true than say it so people can manage their own roadmaps. I say this because it just feels like the team is hoping for no adoption of dart angular web components so that people are not a using Google of another dropped project after flutter web comes out ( or whatever it will be called ).
Am not going to apologise for saying all these things above because it's pretty clear.
You even have your own PO / PM trying to get some energy / integrity into the way things are managed here.

@TedSander

This comment has been minimized.

Show comment
Hide comment
@TedSander

TedSander Jul 5, 2018

Contributor

Thank you @gedw99 for your passion around Dart.

Yes Dart2.0 was a lot of work. For the angular_components team too. I'm glad all our hard work is being appreciated. I'm also glad you are enjoying the flutter components.

angular_components itself is not going anywhere. Google has a lot of projects at Google using these components and systems and they are not going away anytime soon. In fact this may be a reason that you aren't happy with the velocity of the team. We have millions of lines of code dependent on these systems which can make changes difficult. For example the table was intertwined with many of these big projects, and open sourcing it we knew was going to be a large project as we couldn't impact any of these projects negatively. Which is why we couldn't give a date for when this might happen. Most of the Dart development from product teams using Dart in Google is using angular_components so we must be careful and deliberate about the changes. Flutter on the other hand can make changes more easily.

We are happy with the progress of open sourcing table, but don't want to give a date until we can be sure we can hit it. I'm very hopeful that it will be done by the end of the year, but there are still a couple of complexities which could make that date slip.

If devs like mdc-web they can actually use it with AngularDart also. We are actually doing it and you should start seeing more components released with mdc-web as the base. This is actually pretty easy and I don't see this as compelling reasons for people not choosing Dart and AngularDart.

Is there anything specifically that you would like to see or we are missing beyond components we have already discussed in this thread or elsewhere (data table, grid, footer?) We do like the constructive feedback. We released slider, datepicker, and stepper off of user requests.

Contributor

TedSander commented Jul 5, 2018

Thank you @gedw99 for your passion around Dart.

Yes Dart2.0 was a lot of work. For the angular_components team too. I'm glad all our hard work is being appreciated. I'm also glad you are enjoying the flutter components.

angular_components itself is not going anywhere. Google has a lot of projects at Google using these components and systems and they are not going away anytime soon. In fact this may be a reason that you aren't happy with the velocity of the team. We have millions of lines of code dependent on these systems which can make changes difficult. For example the table was intertwined with many of these big projects, and open sourcing it we knew was going to be a large project as we couldn't impact any of these projects negatively. Which is why we couldn't give a date for when this might happen. Most of the Dart development from product teams using Dart in Google is using angular_components so we must be careful and deliberate about the changes. Flutter on the other hand can make changes more easily.

We are happy with the progress of open sourcing table, but don't want to give a date until we can be sure we can hit it. I'm very hopeful that it will be done by the end of the year, but there are still a couple of complexities which could make that date slip.

If devs like mdc-web they can actually use it with AngularDart also. We are actually doing it and you should start seeing more components released with mdc-web as the base. This is actually pretty easy and I don't see this as compelling reasons for people not choosing Dart and AngularDart.

Is there anything specifically that you would like to see or we are missing beyond components we have already discussed in this thread or elsewhere (data table, grid, footer?) We do like the constructive feedback. We released slider, datepicker, and stepper off of user requests.

@gedw99

This comment has been minimized.

Show comment
Hide comment
@gedw99

gedw99 Jul 6, 2018

gedw99 commented Jul 6, 2018

@TedSander

This comment has been minimized.

Show comment
Hide comment
@TedSander

TedSander Jul 20, 2018

Contributor

For the latest release you can see the mdc-web approach. We use it for material-card so you can see how we did it.

RTL works today. We use it internally, but we should provide a smoother flow for external users. We need to figure out how to work CSS Janus into the external build system.
If we provide grid it will be the mdc-grid. I don't see us re-inventing the wheel here.
We have had a roadmap for every quarter, and @nshahan needs to update it for this quarter. Honestly this is how we work at Google and I have no plans to publish any type of Roadmap beyond quarterly.

Contributor

TedSander commented Jul 20, 2018

For the latest release you can see the mdc-web approach. We use it for material-card so you can see how we did it.

RTL works today. We use it internally, but we should provide a smoother flow for external users. We need to figure out how to work CSS Janus into the external build system.
If we provide grid it will be the mdc-grid. I don't see us re-inventing the wheel here.
We have had a roadmap for every quarter, and @nshahan needs to update it for this quarter. Honestly this is how we work at Google and I have no plans to publish any type of Roadmap beyond quarterly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment