QRCode component #190

New Issue

claunia · 2026-01-29T17:33:05Z

claunia commented

2026-01-29 17:33:05 +00:00

Originally created by @enchev on GitHub (Sep 2, 2021).

https://forum.radzen.com/t/feature-request-qr-code-generator/8864

Originally created by @enchev on GitHub (Sep 2, 2021). https://forum.radzen.com/t/feature-request-qr-code-generator/8864

claunia added the enhancement label 2026-01-29 17:33:05 +00:00

claunia closed this issue

2026-01-29 17:33:06 +00:00

claunia commented

2026-01-29 17:33:06 +00:00

@brcaswell commented on GitHub (Oct 14, 2021):

an interesting feature. Are we open to adding dependencies? if so, what sort of SLA or Licensing is acceptable?

@brcaswell commented on GitHub (Oct 14, 2021): an interesting feature. Are we open to adding dependencies? if so, what sort of SLA or Licensing is acceptable?

claunia commented

2026-01-29 17:33:07 +00:00

@akorchev commented on GitHub (Oct 14, 2021):

Are we open to adding dependencies?

That's a great question which requires an elaborate answer.

TL. DR. We don't want to add any third party dependencies to Radzen.Blazor. The only exception that we made is for the Google Maps API. The sheer effort required to create a map component is beyond our capabilities not to mention the mapping data required.

Here are the reasons we have against adding third party dependencies (which a lot of other vendors are doing):

SLA and licensing compatibility. A third party library can change its license at any time (for example move to an incompatible one).
There is probably an existing Blazor wrapper for that library (e.g. ChartJS, Fullcalendar, Bootstrap, HighCharts).
The author/vendor of that library could be planning to release such a wrapper themselves.
Adding new features and fixing bugs in a third party library could be very difficult. Pull requests and releases are beyond our control. There is a pretty high chance we can't even fix the bug or implement the feature due the lack of knowledge.
Styling and themes. We would have to style the third party library to match the existing themes.
Bundling the third party assets is weird. Should we include the JS in the Radzen.Blazor nuget package? Should we ask the end user to include the assets themselves? Should we use a CDN? Thank goodness, this is easy with the Google Maps API - it can only be included from their CDN.
JS libraries prone to be difficult to integrate with Blazor. For example how does one render an existing Blazor component inside a Fullcalendar slot?

This is why we decided to "reinvent the wheel" by implementing our own Chart, Scheduler and HTML editor even though we know a lot more popular and powerful third party open source libraries exist. Isn't most of software reinventing the wheel though?

@akorchev commented on GitHub (Oct 14, 2021): > Are we open to adding dependencies? That's a great question which requires an elaborate answer. **TL. DR.** We don't want to add any third party dependencies to Radzen.Blazor. The only exception that we made is for the Google Maps API. The sheer effort required to create a map component is beyond our capabilities not to mention the mapping data required. Here are the reasons we have against adding third party dependencies (which a lot of other vendors are doing): - SLA and licensing compatibility. A third party library can change its license at any time (for example move to an incompatible one). - There is probably an existing Blazor wrapper for that library (e.g. ChartJS, Fullcalendar, Bootstrap, HighCharts). - The author/vendor of that library could be planning to release such a wrapper themselves. - Adding new features and fixing bugs in a third party library could be very difficult. Pull requests and releases are beyond our control. There is a pretty high chance we can't even fix the bug or implement the feature due the lack of knowledge. - Styling and themes. We would have to style the third party library to match the existing themes. - Bundling the third party assets is weird. Should we include the JS in the Radzen.Blazor nuget package? Should we ask the end user to include the assets themselves? Should we use a CDN? Thank goodness, this is easy with the Google Maps API - it can only be included from their CDN. - JS libraries prone to be difficult to integrate with Blazor. For example how does one render an existing Blazor component inside a Fullcalendar slot? This is why we decided to "reinvent the wheel" by implementing our own Chart, Scheduler and HTML editor even though we know a lot more popular and powerful third party open source libraries exist. Isn't most of software reinventing the wheel though?

claunia commented

2026-01-29 17:33:07 +00:00

@akorchev commented on GitHub (Oct 14, 2021):

Now about the QRCode itself. We did our research and thanks to this great tutorial we found out that implementing a QR code is not so trivial task. There are a lot of nuances: data size for example requires different QRCode sizes, there is built-in error correction etc. This is why we are postponing the implementation for now.

@akorchev commented on GitHub (Oct 14, 2021): Now about the QRCode itself. We did our research and thanks to this [great tutorial](https://www.thonky.com/qr-code-tutorial/introduction) we found out that implementing a QR code is not so trivial task. There are a lot of nuances: data size for example requires different QRCode sizes, there is built-in error correction etc. This is why we are postponing the implementation for now.

claunia commented

2026-01-29 17:33:07 +00:00

@akorchev commented on GitHub (Oct 23, 2025):

Done: https://blazor.radzen.com/qrcode

@akorchev commented on GitHub (Oct 23, 2025): Done: https://blazor.radzen.com/qrcode

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/radzen-blazor#190