feat: add message component #1082
No reviewers
Labels
No Label
area/internal-code
changes requested
confirmed
dependencies
duplicate
good first issue
help wanted
hosting
invalid
kind/bug
kind/feature
question
wontfix
No Milestone
No project
No Assignees
3 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#1082
Loading…
Reference in New Issue
No description provided.
Delete Branch "feature/message"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR adds a simple message component that replaces bulma's default message.
Hi konrad!
Thank you for creating a PR!
I've deployed the changes of this PR on a preview environment under this URL: https://1082-featuremessage--vikunja-frontend-preview.netlify.app
You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.
Have a nice day!
The message styles are still used in:
Use new component also for (and adapt styles):
Remove message styles from notification.scss (maybe it can removed completely – not sure what the remaining styles are for).
The notification class also seems super related. I think those should be merged (?).
@ -0,0 +15,4 @@
padding: .75rem 1rem;
border: 1px solid var(--primary);
background: hsla(var(--primary-hsl), .05);
margin: .5rem 0;
Remove margin (we don't know all contexts this component will be used in).
Done.
I've moved all uses of bulma's message and notification classes to the new message component while adding a few variants for success, danger and warning messages.
I'd like to keep that - it wasn't using the "old" message style before anyway.
I couldn't find any other uses of it and removed it.
Bulma has a concept of a message and a notification. Both are similar but not the same. I think it makes sense to unify them and have only one notification style message component. The one component I added for that looks a lot cleaner as well IMHO.
@ -0,0 +1,41 @@
<template>
<div class="message" :class="[is]">
picky: remove brachets
Done.
@ -0,0 +6,4 @@
<script setup>
const props = defineProps({
is: {
is
as a prop is already used by vuescomponent
component. There it indicates the component / tag. Since the meaning of this prop name is already taken I think we should use something different here. E.g.variant
which is used in the modal.vue.I like
variant
- changed it.@ -0,0 +18,4 @@
padding: .75rem 1rem;
border-radius: $radius;
&, &.info {
No need for the first
&
: the default prop already solves this.Done.
@ -0,0 +23,4 @@
background: hsla(var(--primary-hsl), .05);
}
&.danger {
Don't indent classes: adds more (not needed) specifity.
Done.
Sure 👍
🥳
I didn't even completelty realize this :D
But much better this way =)
After that small fix all good to merge =)
@ -0,0 +6,4 @@
<script setup>
// eslint-disable-next-line no-unused-vars
const props = defineProps({
Disabling might be prevented by removing
const props =
.That seems to work! I thought setting the prop with
const props = ...
was required for props to work.The props are automatically exposed via the context
Neat, I didn't know that.
I think that's a composition api only thing. AFAIK with the option api you get the props in the render function via that
$props
argument.Just saw: the tests also seem to need an adjustment
Tests should be fixed now.