Skip to content
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

Adaptive Scaffold Widget Package Boilerplating #2377

Closed
wants to merge 40 commits into from

Conversation

youssef-attia
Copy link
Contributor

@youssef-attia youssef-attia commented Jul 25, 2022

The initial boilerplate for the AdaptiveScaffold suite. First stage in a multistage release. The next stages will introduce actual functionality and examples.

#108827

Described further in the design doc

@youssef-attia youssef-attia marked this pull request as ready for review July 28, 2022 23:25
@youssef-attia youssef-attia changed the title (WIP) Adaptive Layout Helper Widgets Adaptive Layout Helper Widgets Jul 28, 2022
@youssef-attia youssef-attia changed the title Adaptive Layout Helper Widgets Adaptive Layout Helper Widgets Boilerplating Aug 1, 2022
@flutter-dashboard
Copy link

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Copy link

@dkwingsmt dkwingsmt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor change requests

packages/adaptive_helper/example/pubspec.yaml Outdated Show resolved Hide resolved
packages/adaptive_helper/example/pubspec.yaml Outdated Show resolved Hide resolved
packages/adaptive_helper/example/web/manifest.json Outdated Show resolved Hide resolved
packages/adaptive_helper/example/web/manifest.json Outdated Show resolved Hide resolved
packages/adaptive_helper/pubspec.yaml Outdated Show resolved Hide resolved
packages/adaptive_scaffold/pubspec.yaml Outdated Show resolved Hide resolved
packages/adaptive_scaffold/pubspec.yaml Outdated Show resolved Hide resolved
packages/adaptive_scaffold/pubspec.yaml Outdated Show resolved Hide resolved
packages/adaptive_scaffold/pubspec.yaml Outdated Show resolved Hide resolved
packages/adaptive_scaffold/pubspec.yaml Outdated Show resolved Hide resolved

library adaptive_scaffold;

/// A Calculator.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we checking in a package with no actual functionality? We should wait until we have at least some useful, real content before landing a package (and especially before publishing a package, which this PR will do currently.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because of the size of the PR. It was recommended to split it into 3 PRs to make it easier to review. This PR would just hold boilerplate, the next would hold code/tests, and the last would hold the examples. I expect the PRs to be sent out in succession so it would be fully out before anyone could use it in some stable version. Is this not a good way to handle it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's going to be landed without any functionality, it should have publish_to: none in the pubspec until it's actually a useful package.

This seems like an odd cut-point to me though; there's almost nothing in this PR that requires actual review since it's almost all boilerplate, so I'm not sure how including initial functionality would make reviewing it harder. But if @dkwingsmt feels strongly about landing this now, it needs to not be published.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think just having the boilerplate at first makes it easier to drop the perceived changes significantly and makes the review process simpler for everyone involved. I've added the publish_to:none flag but if there's anything else you'd like me to do to make this more streamlined please let me know. Thanks.

packages/adaptive_scaffold/pubspec.yaml Outdated Show resolved Hide resolved
packages/adaptive_scaffold/pubspec.yaml Show resolved Hide resolved
packages/adaptive_scaffold/pubspec.yaml Outdated Show resolved Hide resolved
@stuartmorgan
Copy link
Contributor

Also, please update the PR description to describe the PR, not the project. It's fine to link to the design document for context (although there should also be an issue tracking this, ideally, which you would link to for easier tracking), but the primary description should be of what is in this PR, not what the whole project will be.

@youssef-attia youssef-attia changed the title Adaptive Layout Helper Widgets Boilerplating Adaptive Scaffold Widget Package Boilerplating Aug 2, 2022
@youssef-attia youssef-attia self-assigned this Aug 2, 2022
@youssef-attia
Copy link
Contributor Author

Moved to #2406.

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

Successfully merging this pull request may close these issues.

3 participants