New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add interactive features to request and select symbols #31
Comments
I feel like it might be useful to follow a similar model to FontAwesome when it comes to making these symbols available to developers for their innovate apps. I can go into more detail about how I see this working for us if that helps? |
Do tell! It's a mature package and is popular so they are probably doing something right. Made me think a npm package is probably as useful as an REST API these days. Especially as buildtime resource acquisition often beats run time (eg static sites) |
Thanks so much and I am copying in Russell who has been linking up all the symbol sets. I need to understand the concept behind it all!!
Best wishes
E.A.
Sent from my mobile phone
On 13 Feb 2019, at 07:42, Steve Lee <notifications@github.com<mailto:notifications@github.com>> wrote:
Do tell! It's a mature package and is popular so they are probably doing somehting right.
Made me think a npm package is probably as useful as an REST API these days. Especially as buildtime resource acquisition often beats run time (eg static sites)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#31 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAtX3P_0V2YGoO2BBGarSveOK1Qr_j3Bks5vM8HmgaJpZM4a2ZlE>.
|
There would be 1 centralized symbols repo and its only concern is to add new symbols. Every time this repo is altered it would trigger releases of all of the distributions. There would then be multiple distribution versions such as Vanilla JS, React, Vue, and many more. They would all come in their own git repo and be totally automated. You can then expand your distributions really easily and not have to worry about keeping the symbols up to date. Personally I would rather get the symbols in an NPM package rather than a REST API if I was developing a website, but I think that might be personal preference more than anything. |
@gavinhenderson Do we actually need version for different frameworks? I'd like to avoid that if required as even if autmated it's complexity to manage. Would a plain Module of the right type (ES now?) not work almost everywhere Web front end now a days. We could perhaps provide sample wrappers. Needs more discussion. |
Yeah that is a good point. I think having simple wrappers for different frameworks does add value as it removes all work for the end developer. I think making the library super easy to use can really increase usage of the package. That being said I agree with you it does add unnecessary complexity to the automation so they can be ignored for now and examples of how to use it in different frameworks would suffice. Then maybe they can be reconsidered once at a later date. |
I just realised that now we have a web page of all the symbols you can individually download any symbols you like
It's not ideal as the symbols name gets lost but acts as a temp workaround. |
It looks like this could be done in GlobalSymbols - see #30 |
The original straight-street website which held the Mulberry symbols provided several interactive features for managing the symbols
These were all dropped on the copyright assignment and the related move to mulberry-symbols.org. The idea was to keep everything light weight until new requirments and or funding arose. Plus the codebase had an enourmous amount of technical debt.
Let's discuss what similar features might be useful and how to add them....
The text was updated successfully, but these errors were encountered: