Regarding the performance, I can ensure you there is no problem with that. The mapping is cached, it will not map every time. The levels communication is not an issue in real projects. The widget tree should be designed in optimized layout even if you try other state management. You can check the performance of the example by calculating the duration of timeframe or execution. I did apply to the reproduced complex projects and there is no problems as long as you truly understand my concept. Again, this is only testified by others. My words mean nothing anyway.
What was the inspiration for this package? Which packages or patterns inspired you to create your state management package?
Well, the motivation was the problems I encountered during projects development; and the inspiration was the Flutter tree and real lifeā companies and firms human resources or employee tree 
. No kidding at all. Consider an application is a company and all components are its employee forming a hierarchy structure. We have CEO manages multiple departmentās head, who manage multiple members.
Regarding paper, it carries a whole state, or just part of state (attributes of an object). It signal the subscribers the changes; and also what should the state or some attributes should change to. It is different from Blocās event, which is treated as merely as a trigger for according actions; and also from Blocās state because papers are always considered to carry some attributesā changes, not a whole state.
Recall the Toggle example mentioned earlier. A toggle has 2 states: on and off, or true and false. There will be a paper named Switch Switch { final bool mode }, and the toggle update its state base on Switch.mode. When toggle is off and users tap it, it will then process a paper Switch(true), change state to true. Then, the paper will be reported to its parent - HomeScreen like āHey boss, I have changed to true, do whatever you need to!ā. The Switch is also can be a ācommandā to the toggle by HomeScreen. Like later, the HomeScreen creates Switch(false) and sends it to the toggle: āHey, process this oneā 
.
About the mapping handlers, it is just about code syntax or implementation. Honestly, it does not relate to Bloc. I am thinking about code generator to make it more convenient in next version (hope the package is still alive ).
Iām not sure what your package do better than other state management solutions
Like I mentioned, the ultimate goal is the maintenance of code base. I cannot explain and demonstrate you how and why in details. To be able to see the problem I encountered, the projects have to be big. seriously complex in the way the UI behaviors and the connections of features.
In the projects I refer to, there were widgets that subscribes to average of 3 to 6 blocs so there would be a lot of logic inside the widget to react correctly with different combination of states from different blocs. When adding more features, it was harder to ensure the current behaviors remain untouched. And when it is need to be fixed; it was hard to debug (widgets are triggered to rebuild multiple times and send many events to many blocs; then blocs emit new states. It is like nuclearās reactions 
).
All of these are just words. Maybe I am a poor-skilled developer; did not set up correctly, did not integrate properly following the pattern, etc. Or even with same circumstances, you may not see it as problems but just an ordinary things to work with. It is too personal and subjective. Therefore, all I can do is just recommend you to keep in mind the concept and idea of tree layout; try applying to your current projects; and picturing how it goes.
Letās say we have authentication feature which has SignUpScreen, SignInScreen. One of the most common and basic requirements are info validations; like passwords, emails, etc have to meet some conditions. Most of the time, developers will create ViewModels of sign up and sign in (blocs, providers, etc); and put the validation code into them. SignUpScreen and SignInScreen will subscribe to them and rebuild UI.
Now try to apply my idea into it. There would be no such ViewModels. Instead, let the SignUpScreen; SignInScreen manage their states by themselves. Imagine we have App is the parent of the screens. App will train them like: āHey SignUpScreen, whenever users filling in infos, check them and show the errors text when they fail to meet validation. Otherwise, report to meā. If App receives the āreportā (via paper, or callbacks), it means all the infos are good to go; and it will command AuthenticationService (another Appās child) to make request to sign up. if the request return with success, App command SignUpScreen to go away and command SignInScreen to come in. If there are error, App will command SignUpScreen to show error or do something different defined by the featureās requirements. Or you can let the App to handle the validation and command SignupScreen to show errors. Choose which one is depend on the projects nature: scope, behaviors, etcā¦ You can write a documentation for the projects with a list of components and what they can do so other developers can follow.
I will list out pros and cons of these two approaches because again you can only experience them by yourself. Just keep in mind the idea and try applying to others things as well.