This is a new component that Slack supports Datetimepicker where date and time components are in the same row.
This new component takes number which I think it should be int64 for golang because Go's epoch API returns int64 data type.
Since datetimepicker takes two columns, it's not supported in Accessory. So, I don't include it as part of Section serialization/deserialization.
PS. Sorry I deleted and restored a couple times. First didn't realize that I pushed the upstream, then I changed my mind because I tested it and it's working as expected.
Pull Request Guidelines
These are recommendations for pull requests.
They are strictly guidelines to help manage expectations.
PR preparation
Run make pr-prep from the root of the repository to run formatting, linting and tests.
Should this be an issue instead
[ ] is it a convenience method? (no new functionality, streamlines some use case)
[ ] exposes a previously private type, const, method, etc.
[ ] is it application specific (caching, retry logic, rate limiting, etc)
[ ] is it performance related.
API changes
Since API changes have to be maintained they undergo a more detailed review and are more likely to require changes.
no tests, if you're adding to the API include at least a single test of the happy case.
If you can accomplish your goal without changing the API, then do so.
dependency changes. updates are okay. adding/removing need justification.
Examples of API changes that do not meet guidelines:
in library cache for users. caches are use case specific.
Convenience methods for Sending Messages, update, post, ephemeral, etc. consider opening an issue instead.
This is a new component that Slack supports
Datetimepicker
where date and time components are in the same row. This new component takes number which I think it should be int64 for golang because Go's epoch API returns int64 data type. Sincedatetimepicker
takes two columns, it's not supported in Accessory. So, I don't include it as part of Section serialization/deserialization.PS. Sorry I deleted and restored a couple times. First didn't realize that I pushed the upstream, then I changed my mind because I tested it and it's working as expected.
Pull Request Guidelines
These are recommendations for pull requests. They are strictly guidelines to help manage expectations.
PR preparation
Run
make pr-prep
from the root of the repository to run formatting, linting and tests.Should this be an issue instead
API changes
Since API changes have to be maintained they undergo a more detailed review and are more likely to require changes.
Examples of API changes that do not meet guidelines: