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

Controls' properties' types should be given in the documentation. #305

Open
taaaf11 opened this issue Jun 23, 2024 · 14 comments
Open

Controls' properties' types should be given in the documentation. #305

taaaf11 opened this issue Jun 23, 2024 · 14 comments

Comments

@taaaf11
Copy link
Contributor

taaaf11 commented Jun 23, 2024

It would be easier if types of properties are also given in the documentation.

Perhaps like this:

value: str
The text displayed.

(From the Text documentation page.)

@ndonkoHenri
Copy link
Contributor

You can actually help with that, if you want :)
Here's an example: https://flet.dev/docs/controls/image#fit

@taaaf11
Copy link
Contributor Author

taaaf11 commented Jun 23, 2024

Thank you!

@taaaf11
Copy link
Contributor Author

taaaf11 commented Jun 23, 2024

Should the changes be like bool or Optional[bool] where it is optional?

@taaaf11 taaaf11 closed this as completed Jun 23, 2024
@taaaf11 taaaf11 reopened this Jun 23, 2024
@ndonkoHenri
Copy link
Contributor

ndonkoHenri commented Jun 23, 2024

(Almost) all properties are actually optional, so let's just mention the main type: bool

If you are hopping on this, please make sure to follow the style used "Value is of type ... [and defaults to ...]" :)

@taaaf11 taaaf11 changed the title Document properties' types should be given in the documentation. Controls' properties' types should be given in the documentation. Jun 24, 2024
@taaaf11
Copy link
Contributor Author

taaaf11 commented Jun 24, 2024

Bruh, I have a question. Can I just "copy/paste" the values from function (property) definitions and see the def_value from there or is there something more to do, like with the action_button_padding with type of PaddingValue which is of course a union.

@ndonkoHenri
Copy link
Contributor

def_value is the default value of a property.
Not all props have one though. But if the property you are willing to document has one, then you can mention it.

Concerning stuffs like PaddingValue, I think you can just write it like that in the docs too. We could then add a section/page in the docs (still thinking of how it could be named) for all of these types, with more information on the possible values.

@taaaf11
Copy link
Contributor Author

taaaf11 commented Jun 24, 2024

Got it!

As many of the PaddingValue things are also in the docs, I suggest the name of the section as "Type Aliases". This is also a name of a new feature in python.

@taaaf11
Copy link
Contributor Author

taaaf11 commented Jun 24, 2024

Now there are conflicting types, there is a PaddingValue and a padding.Padding. I think I should leave those properties in the docs as they are in which type is given padding.Padding. They accept PaddingValue. What do you think?

@ndonkoHenri
Copy link
Contributor

ndonkoHenri commented Jun 24, 2024

I suggest the name of the section as "Type Aliases". This is also a name of a new feature in python.

Nice suggestion, thanks. So, we could have "Aliases" page under "References/Types" section of the docs. Will you like to create the file for this? (aliases.md under docs/references/types)

Now there are conflicting types, there is a PaddingValue and a padding.Padding.

If we have this aliases page, we could then set the value-type of all padding-related props to PaddingValue, which has link to the aliases page (it will look like /docs/references/types/aliases#paddingvalue).

This will fix the conflict, right?

@taaaf11
Copy link
Contributor Author

taaaf11 commented Jun 25, 2024

Will you like to create the file for this?

Sure!

@taaaf11
Copy link
Contributor Author

taaaf11 commented Jun 25, 2024

A quick question @ndonkoHenri

Should it look like this

### PaddingValue

Union of int, float, Padding and None.

I have sent a pull request in exactly this format.

@ndonkoHenri
Copy link
Contributor

Can we close this issue as completed @taaaf11 ?

@taaaf11
Copy link
Contributor Author

taaaf11 commented Jul 18, 2024

For now, the laptop on which I write this code is not in working condition, and I don't know how much I would have to wait for that. As this issue is related to all controls, I think it should be kept opened. What is your opinion?

@ndonkoHenri
Copy link
Contributor

Alright, no prob, let's keep it opened.

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

No branches or pull requests

2 participants