I have some persistent configuration in the configuration registry that must be passed into some JS codes specific to my add-on.
In detail:
This JS codes requires some hyphenation related configuration stored within Plone. Right now it is fetched using AJAX with the help of a browser view...working but not very nice and efficient...is there a better more canonical way in Plone 5?
Considering how you have implemented your JS, I think your AJAX call to a browser view is probably the best approach.
If you had implemented a Mockup pattern, you would have a better option: you would pass the settings value as attributes in the markup, like this: <div class="pat-hyphenator" data-pat-hyphenator="selectors:p.myText;minwordlength:15">Here is my text</div>
That way, it is easy to collect every data you need in Python, and pass them to the pattern in ZPT: <div class="pat-hyphenator" tal:attributes="data-pat-hyphenator view/hyphenConfig" tal:content="context/text" />
The whole idea with Mockup(/PatternLibs) is to create completely autonomous components which can be developped, compiled and tested outside of Plone, and all the settings and data inputs are provided in the markup.
Not sure about AJAX being the best approach. I could move the variables into some viewlet code (either holding the data as JS variables or as data attributes on some hidden element). This would eliminate at least a bit of network latency. I don't the purpose Mockup here since I am not working on UI components.
Forget about JS variables, data attributes are way much better.
There are many reasons for that, let's mention 2 of them:
script tags in the wild might be easily forget when writing Diazo rules,
script tags are not considered when loading a page in AJAX (for instance in a modal).
Note: I think hyphenation is 100% UI related, and it would be a very useful pattern to add to Mockup (if we could just add a class pat-hyphenator on any paragraph to have it hyphenated properly, it would be great).
In such case, a hidden form input often works well as a place to hold JSON (and you could traverse to your existing view from your template, instead of by AJAX). I suppose these days, with html5, you can just use any element you want want with a data- attribute as alternative to using a hidden form input.