Replies: 2 comments 1 reply
-
I am a huge enthusiast of the functional programming paradigm. I enjoy using higher-order functions to improve the code style and usability in C#. The first place where I consciously observed this particular pattern was the query builder in the ElasticSearch client. Later, at my job, I started building various libraries: to configure generalized frontend pages and handle events from them, to generate reports or handle incoming events from external resources. Making such configurations in pure JSON (or any other format) is not very safe. Therefore, I decided to build such a configuration with Fluent API (therefore with static code analysis, IntelliSense, etc.), functional programming and expression trees. As we have very complex, deeply nested hierarchies, I needed a way to reduce nesting and make such configuration code as concise and possible. Several iterations later, many trials and errors and we have API design in QuestPDF 😁 Please notice that QuestPDF follows a very strict rule: every component needs to be as simple as possible, composition over complexity. This was inspired by Flutter. Therefore, instead of creating a complex element that handles border, padding, alignment, etc. (like in HTML), I have created several elements responsible for one functionality at a time. This makes the implementation manageable but increases the number of required elements substantially. Without a proper way of chaining and reducing nesting, working with such code would be difficult. Personally, I would like to see a UI library that follows a similar pattern 😝 Scrolling through all properties/events/methods in WPF is a nightmare... |
Beta Was this translation helpful? Give feedback.
-
Fascinating background on how you arrived at the design. Thank you for sharing! And yes..... Wpf (and frankly every one of the XAML frameworks) are a total disaster. 1 month of trying WPF made me denounce the entire ecosystem. I go elsewhere for GUI work. |
Beta Was this translation helpful? Give feedback.
-
I began scrutinizing the delegate-arg pattern to understand what really makes it tick.
You have this example code on the readme:
Without the delegate argments, the code would have to be rewritten as something like this:
Pitfalls of the non-delegate version:
Delegate variant eliminates all the pitfalls above. I'm curious to know if I've interpretted correctly. And also, where did you get the inspiration for this from? I don't think I would have reached for this intuitively in any API I design, but now that I get it, it seems awesome!
Beta Was this translation helpful? Give feedback.
All reactions