Update Link Titling by client #27
No reviewers
Labels
No labels
bug
dependencies
documentation
duplicate
extension
feature request
fixed
frontend
good first issue
help wanted
improvement
invalid
investigating
javascript
planned
question
released
server
wontfix
work in progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sofa/webcrate!27
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feature-link-user-titling"
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?
Here is a small (mostly UX) Feature which I think which improves the User Experience by giving more control of a link to the user.
The Problem: Sometimes I create a Link but I am not happy with the default titling of a link (the website title). F.e. I want to save links to job postings but don't want the website title of the recruitment platform as the link title.
With this feature you can add a custom title to the link (optional - then the default way of titling will be used).
Also I changed the UI of the Update-Title component input element for UX reasons. First I haven't understand that I can change the title because of the similarity of the title input element to a normal headline.
Changelog
Hey, thanks for taking the time to create this PR!
I like the first change being able to add a title when creating a link, it can definitely save some time and doesn't disturb otherwise.
I am going to reject the second change for now. I think it is unnecessary to constantly display an input for the link title in the details view and I don't like how it looks. I get your point though and will think about ways to indicate that the title can be changed.
If you remove the styling change (commit https://github.com/WebCrateApp/webcrate/pull/27/commits/46d8c30ef1653839b2d578257ee9d231b265e3b4) I will merge this PR.
And again for the future: It's best to create separate PRs for different changes, makes it easier to review :)
Hello, yeah I understand what u mean I also thought some time about the second change. I just didn't found any other way to solve this problem.
I made those two changes in one PR because those are two similiar problems.
No worries, it's just that as you see the one change could be merged directly while the other needs some additional work. Reducing PRs to only the most relevant change/a single commit makes easier and faster to review as I can go through one change at a time.
No problem though, just remove the one commit or create a new PR and I will include this in the next release (should be out tomorrow) 😄
Thanks again!
🎉 This PR is included in version 1.1.0 🎉
The release is available on GitHub release
Your semantic-release bot 📦🚀