manuel
29 يوليو 2022، 2:58م
1
حالياً، يتم تخزين أسماء العلامات في السمة data-tag-name:
هل يمكن أن تكون هناك أيضاً سمة data-tag-group؟ سيجعل ذلك من السهل تنسيق وتمييز العلامات من مجموعات مختلفة على واجهة المستخدم. حالة استخدام أجدها مفيدة بشكل خاص هي في الإعدادات التي تستخدم العلامات فقط. عندها سيكون لديك على الأرجح بعض العلامات العليا، وسيؤدي ذلك إلى جعل التنقل أكثر سهولة عندما تبرز العلامات من تلك المجموعة بمظهر مميز.
رأيت أن هناك طلباً منذ سنوات لإضافة فئة CSS . أثير هذا الموضوع مرة أخرى حيث قد تكون الأمور قد تغيرت وربما يكون من الأسهل تنفيذه باستخدام سمات البيانات أيضاً؟
12 إعجابًا
هل يمكن استخدام هذا لتعيين أيقونات العلامات بناءً على مجموعة العلامات أيضًا؟ إعدادات أيقونة العلامة الخاصة بي قاسية جدًا حاليًا، وشيء لتقليصها سيكون
3 إعجابات
manuel
23 يونيو 2024، 4:19م
3
أعتقد ذلك. بالإضافة إلى المكونات الأخرى التي تغير أنماط العلامات، مثل Discourse Coloring Tag أو Colored Tag Styles .
ستحتاج المكونات إلى التعديل لتنفيذ ذلك. في حالة أنماط العلامات، سيكون ذلك مباشرًا جدًا على الرغم من ذلك.
إعجابَين (2)
نفس الشيء. لدي ما يقرب من ألف سطر ستصبح 8.
إعجابَين (2)
ملاحظة لمشاركتها بأنه تم العمل على هذا ولكنه وُجد لاحقًا أنه تغيير كبير، لذلك تم إغلاقه. إنها فكرة رائعة ولكن ليس من المؤكد أن يقوم الفريق بالتقاطها في أي وقت قريب للأسف.
main ← add-tag-groups-for-tag
opened 07:55AM - 17 Jul 24 UTC
## Overview
This commit adds the `data-tag-groups` attribute to tags, making … it easier to use CSS selectors to batch select tags belonging to certain tag groups.
An example:
```html
<a href="/tag/hidden" data-tag-name="hidden" data-tag-groups="Hidden Tag Group, non-hidden tags" class="discourse-tag box">hidden</a>
```
Related meta topic: https://meta.discourse.org/t/add-a-data-tag-group-attribute-for-tags/234410
## Detailed changes
Add data-groups to these...
- [ ] Tags for topics
- [x] The effect has been shown
- [ ] Tests already written
- [ ] Confirms that there are no performance issues
- [ ] TagChooser at the top of TopicList
- [x] The effect has been shown
- [x] Tests already written
- [ ] Confirms that there are no performance issues
- [ ] Tags on the sidebar
- [x] The effect has been shown
- [ ] Tests already written
- [ ] Confirms that there are no performance issues
- [ ] Tags on the `/tags` page
- [x] The effect has been shown
- [ ] Tests already written
- [ ] Confirms that there are no performance issues
- [ ] Search bar tags
- [x] The effect has been shown
- [ ] Tests already written
- [ ] Confirms that there are no performance issues
- [ ] Composer tags chooser
- [x] The effect has been shown
- [ ] Tests already written
- [ ] Confirms that there are no performance issues
- [ ] ~~Tags in the post body~~ Maybe next PR
## DEV Improvements
Partially rewrote `defaultRenderTag` for better scalability and clarity:
The new `defaultRenderTag` reserves an interface for theme components to avoid the need for components to completely rewrite `defaultRenderTag` to provide custom tag renderer.
For example, you can now replace the tagRenderer like this:
```javascript
api.replaceTagRenderer((tag, params) => {
return defaultRenderTag(tag, params, {
extraClass: "custom-tag-class",
contentFn(old) {
return `${iconHTML("tag")}${old}`;
},
});
});
```
This has a significant benefit for discourse tag icons. Since the [old way of code](https://github.com/discourse/discourse-tag-icons/blob/main/javascripts/discourse/initializers/tag-icons.js#L9-L84) the changes made by this PR will be completely overwritten by discourse tag icons, and the theme component must be updated accordingly.
After applying the new interface, it can automatically synchronize changes with the `defaultRendererTag` in core.
إعجابَين (2)
