The goal of typed_endpoint is to replicate most features supported by
has_request_variables, and to improve on top of it. There are some
unresolved issues that we don't plan to work on currently. For example,
typed_endpoint does not support ignored_parameters_supported for 400
responses, and it does not run validators on path-only arguments.
Unlike has_request_variables, typed_endpoint supports error handling by
processing validation errors from Pydantic.
Most features supported by has_request_variables are supported by
typed_endpoint in various ways.
To define a function, use a syntax like this with Annotated if there is
any metadata you want to associate with a parameter, do note that
parameters that are not keyword-only are ignored from the request:
```
@typed_endpoint
def view(
request: HttpRequest,
user_profile: UserProfile,
*,
foo: Annotated[int, ApiParamConfig(path_only=True)],
bar: Json[int],
other: Annotated[
Json[int],
ApiParamConfig(
whence="lorem",
documentation_status=NTENTIONALLY_UNDOCUMENTED
)
] = 10,
) -> HttpResponse:
....
```
There are also some shorthands for the commonly used annotated types,
which are encouraged when applicable for better readability and less
typing:
```
WebhookPayload = Annotated[Json[T], ApiParamConfig(argument_type_is_body=True)]
PathOnly = Annotated[T, ApiParamConfig(path_only=True)]
```
Then the view function above can be rewritten as:
```
@typed_endpoint
def view(
request: HttpRequest,
user_profile: UserProfile,
*,
foo: PathOnly[int],
bar: Json[int],
other: Annotated[
Json[int],
ApiParamConfig(
whence="lorem",
documentation_status=INTENTIONALLY_UNDOCUMENTED
)
] = 10,
) -> HttpResponse:
....
```
There are some intentional restrictions:
- A single parameter cannot have more than one ApiParamConfig
- Path-only parameters cannot have default values
- argument_type_is_body is incompatible with whence
- Arguments of name "request", "user_profile", "args", and "kwargs" and
etc. are ignored by typed_endpoint.
- positional-only arguments are not supported by typed_endpoint. Only
keyword-only parameters are expected to be parsed from the request.
- Pydantic's strict mode is always enabled, because we don't want to
coerce input parsed from JSON into other types unnecessarily.
- Using strict mode all the time also means that we should always use
Json[int] instead of int, because it is only possible for the request
to have data of type str, and a type annotation of int will always
reject such data.
typed_endpoint's handling of ignored_parameters_unsupported is mostly
identical to that of has_request_variables.
Along with pydantic we add annotated_types for Annotated utils that can
be used for more specific validation constraints.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
We should avoid adding extra fields directly on the server data because
it makes it hard to infer the types for the functions such as
`format_attachment_data`.
_default_manager is the same as objects on most of our models. But
when a model class is stored in a variable, the type system doesn’t
know which model the variable is referring to, so it can’t know that
objects even exists (Django doesn’t add it if the user added a custom
manager of a different name). django-stubs used to incorrectly assume
it exists unconditionally, but it no longer does.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit fixes the issue of reordering the stream list when the
user unsubscribes from a stream. The issue was caused because, on
rendering, we sorted the list by name but did not sort it while
updating the stream list on any update.
Earlier, when a message was sent in a followed topic in
a muted stream, a compose banner warning with a suggestion
to UNMUTE the topic for receiving notifications about new messages
was shown.
This commit fixes the incorrect behavior. No warning is shown
in the case mentioned above because a user, in general, already
receives notifications for messages in FOLLOWED topics.
Commit cf0eb46afc added this to let
Django understand the CREATE INDEX CONCURRENTLY statement that had
been hidden in a RunSQL query in migration 0244. However, migration
0245 explained that same index to Django in a different way by setting
db_index=True. Move that to 0244 where the index is actually created,
using SeparateDatabaseAndState.
Also remove the part of the SQL in 0245 that was mirrored by dummy
state_operations, and replace it with real operations.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
emoji_picker.is_open() much more accurately describes what this does,
and in particular the fact that the function applies to all places the
emoji picker might be.
After this change we add the "reaction_button_visible" class to every
reference element of the emoji popover. There's no need to handle the
user status picker case since the reference element should always be
visible. That's why we're reducing some complexity, even though it
means adding a class to the user status picker reference.
By default, Tippys with the `data-reference-hidden` attribute aren't
displayed. But when we render them as centered overlays on mobile and
use `getReferenceClientRect` for a virtual reference, Tippy slaps this
hidden attribute on our element, making it invisible. We want to
bypass this in scenarios where we're centering popovers on mobile
screens.
The offset modifier is tricky and its calculations is related to the
placement of the popover. So, to prevent inconsistency, we should fix
the placement to some value.
Zixuan James Li
David Rosa
evykassirer
Lalit Kumar Singh
Mateusz Mandera
Anders Kaseorg
Daniil Fadeev
Palash Baderia
Prakhar Pratyush