Develop Reference

Converting an emoji code point to it's shortcut text [closed]

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 10 months ago.
Improve this question
I'm working on a new project and it includes allowing the user to select an emoji from a popup window using the Twemoji project for the emojis. What I'm trying to figure out is if there is a way to get the shortcut text of the emoji. I have access to the url in this fashion https://twemoji.maxcdn.com/v/14.0.2/72x72/1f605.png and I can also convert it to unicode if I need to.
For instance, I want to convert 😀 to :smiley:
I can do it server side (classic asp) or client side (vanilla js or jquery).
Edit: I found a json file that I'm going to import into a database table and do a lookup.
https://raw.githubusercontent.com/iamcal/emoji-data/master/emoji.json

I ended up importing this json file into a local lookup database table. Works for my purpose, might help somebody else too.
https://raw.githubusercontent.com/iamcal/emoji-data/master/emoji.json

There isn't just a built-in way that you'll be able to convert an emoji to something like that. As far as anything is concerned, those are just characters the same as "A" or "!".
The only way to do something like this would be to find or create a library or dictionary which you can look them up.
It looks like the filename part of that URL (1f605) is the Unicode value, so you can feed that into a library.
Normally I'd recommend a library, but flipping through the existing options, none of them really have enough regular usage for me to be comfortable even mentioning one. I'd suggest searching NPM for "emoji" and flipping through the options and see which one you like the best / suits your needs the best.

What would be the best solution to store and work with data in JavaScript without a database? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
Alright, please allow me to elaborate on that. I am trying to build a small application for visual flight planning, to help with the calculations. I am using HTML/CSS/Javascript to make something simple. There are objects for airports, waypoints and airplanes for example. You select an airport for your origin, another for your destination, input the waypoints you will fly through and choose the aircraft, and the app uses the coordinates and airplane characteristics to calculate the legs. It has a few more steps but that's the basic concept.
So what I would like to do is store the data in a separate file and retrieve just the data I need when the element is selected. I am a beginner level, so I don't know if I am day dreaming.
Right now what I did was create an array with all airports, another with all waypoints and another with the aircrafts. A function retrieves the data from the array and returns the object. But that seems like a waste of memory.
Another idea I had was to mae a function with a switch statement, using the ids (airport/waypoint code for example) and returning the object selected. I did this for the magnetic deviation, using the coordinates.
I would like to make something that I can update later in the future, but with a simple structure, if at all possible. SQL sure pops in mind, but I am thinking of something more local. LocalStorage also appears to be an idea, but it would have to be initialized everytime the browser loaded, and still would be a waste of memory

This question is kind of relative, and some people could even view it as opinion-based. However, I think a concrete answer can be found accounting for some details.
Storing it in the application (arrays/objects)
Yes, that's what you're doing now, and that's what you view like a waste of memory, I know. However, depending on your situation, you shouldn't care too much about that.
Anyway, I'd recommend you to keep your data this way when it is not too large and is unlikely to change. Probably this is not the best alternative for you, since you said you pretend to update the data in the future. It's not only about memory, but also about maintainability.
Local web storage
If the solution above is not suitable for you, probably this also isn't. Why? It's simple. In the process of storing data in localStorage, you'll need to have that data in your code, in the form of an array or object. In the end, you'll have the data in your application AND in the local web storage. It doesn't make much sense, don't you agree?
localStorage should be used for storing data which is relative to the user and which will not be accessible for you after the page is left, unless you save it. This kind of storage would be not be a good choice for storing data that will be accessible for you at any condition.
Using a JSON file
This could be a good solution if your data is not likely to change constantly. And it also would meet your expectations, since you could request data from it only when it's needed. You should take your own situation into account, but, from what I could understand from what you said, that is, you have data which is going to change sometimes and it's somewhat large, using a JSON file would be a good if you don't want to use a database.
Finally, there are several advantages, even for static (but somewhat large) data, of using a database. You could opt, for example, for SQLite, that's an embedded database. However, that is a topic for another question.
For now, since your data will change sometimes and is potentially lengthy, using a JSON file looks like the more suitable option within the "no-database" limits.

localStorage is the way to go.
Just save your object with localStorage.setItem('item', JSON.stringify(obj)) and retrieve it later with JSON.parse.
There's no better way to save data locally in the client side.

How does GitHub.com produce it's diff views? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I really like the diff views on GitHub.com. I was hoping to use the same module(s) they use on my website for diffing small json objects in the same beautiful and readable way, but I can't find the source code for GitHub.com, which I believe is close sourced...
Does anyone know how they achieve this result? Which modules they use, for example? Or are there any components out there that clone the GitHub.com diff views?
I'm looking for a module that can help me transform before and after blobs of json into a visual diff like you would see on GitHub.com when looking at a commit. My own solutions shows removed characters in red and added characters in green, but GitHub.com's solution is much more elegant, showing the full lines with a red or green background, but also with the specific characters added or removed sporting a darker background color. I don't need any of the interactivity or line numbers of anything.
Notes:
I looked at gitlab.com, which features a very similar diff view and is fully open source, but if I understand correctly, they produce the diff views on the server side, which is not an option for me at the moment.
I also found https://www.npmjs.com/package/react-diff and modules like that, but I find the result less readable than what I see on GitHub.com.
I am now using https://www.npmjs.com/package/diff to power a custom component that just uses <ins> and <del> to show what was added/removed. This doesn't produce a result anywhere as good as what GitHub.com has, but before spending hours on iteratively improving my custom component, I wanted to make I hadn't simply missed an existing component out there that reproduce the GitHub.com look, hence this question.
I am open to react components, jquery solutions, or anything else. I use react myself, but if I find what I need written for JQuery for example, I should be able to "translate" it. I'm mostly looking for either a react component doing exactly what I want (GitHub.com-style diff view) or something in another framework that can serve as inspiration to get my custom component up to par.

Your question is too broad... and probably that's why this question is going to be closed, but maybe you are looking into something like highlightjs. Js code example:
var c = document.createElement("code");
c.className = "code blink hljs diff";
c.innerHTML = JSON.stringify(varWithYourDiffCode, null, "\t");
hljs.highlightBlock(c);
document.getElementById("root").appendChild(c);

Maybe you're looking into structure of diff file, for example command:
git diff myFile.md
will generate:
-* AVL tree - the **heights of the two child subtrees of any node differ by at most one**.
+* AVL tree - (since 1962) the **heights of the two child subtrees of any node differ by at most one**.
but command:
git diff --word-diff myFile.md
will generate:
* AVL tree - {+(since 1962)+} the **heights of the two child subtrees of any node differ by at most one**.
Screen from my terminal:

Is diff2html the kind of thing you're looking for: https://diff2html.xyz/?
It's a javascript component you can integrate into an existing page. They give examples of angular and raw HTML usage here: https://github.com/rtfpessoa/diff2html#how-to-use

How would I speed up this JSON request process? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Apologies if this is too abstract.
I using mainly jQuery to create a Chrome extension where users can subscribe to feeds. A 'random' selection of items from these feeds are then delivered on the user's new tab page.
Here's the process I'm planning to use. Is this the fastest way of doing it?
Check which feeds the user is subscribed to and use nested $.getJSON requests to bring them in.
Cache these locally for at least the next 12 hours so they can be quickly retrieved again.
Convert the feeds to JSON objects and combine using concat.
Shuffle the items in this new, single, combined feed.
Load the first 36 results (and display using Masonry).
Add an infinite scroll that loads blocks of 36 results when the user scrolls down.
On top of this, I also intend to cache the JSON feeds on the server for 12 hours or so.
Is this the quickest way of going about it? Might it be faster to swap steps 2 and 3 around given that it's not very frequent that a user will subscribe to more feeds?
As the emphasis is on loading speed, there's plenty else I'm happy to sacrifice. For example, it doesn't have to be JSON I use if a database would be better. Similarly, the caching can be for a long period of time because the objects the user is being shown will be in a 'random' order and so needn't be the latest.

You could do most of this on the server side and only send the 36 required feeds, which should load very fast depending on their content.
Your biggest bottlenecks are the following:
Fetching the various feeds (~1 second per feed)
Building a list of those feeds for a specific user
Downloading the feeds to the user's browser
The last two are not terribly long, but the difference between loading 36 presorted items and organizing an arbitrary number of random elements is important when the new tab page is only used for a few seconds.
The easiest solution is to fetch all feeds on the server, put them in a database and retrieve the last 36 matches for the users that need them. This has several advantages:
Fetching from a database takes milliseconds. Fetching a feed from a remote page can take a few seconds.
Databases are made to be queried, so fetching, merging and sorting results is easy.
The short, pre-filtered list of items will download far faster.

How should I organize a large JavaScript dialog object? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a very large JavaScript object I'm using to store RPG dialog, containing several large top-level objects. The dialog is formatted similar to JSON.
When organizing the dialog, should I put each of those top level categories in their own function?
Or maybe their own separate javascript file?
Does keeping all the text in one javascript (var json =) object affect performance?
Any organization tips would be appreciated!

You should generally try to limit coupling whenever possible. Therefore it would make sense to separate these into separate functions, but see point #3 about databases.
You can separate them into separate javascript files if it gets too big to manage easily with one. You can always have a build process that lumps them all together later (check the html5 boilerplate for more on this technique).
It probably isn't going to make much difference for performance at this point. I might suggest using something like mongoDB in the future as you get more data though. Take a look at meteor js to get some inspiration. Using a database can simplify your code if you do it right.

Addressing question 1, this sounds like JSONP? Slightly different.
I would suggest that performance differences would be negligible for parsing though if using JSONP and injecting <script/> elements to the DOM file size becomes a factor, and it would be wise to group related data into seperate files so that it can be retrieved selectively.
Obviously at the top level if not using JSONP, you can seperate your objects into an array or one keyed object.

I saw your question before the edit and to me it wasn't only about JSON. I understand the reasoning behind meagar's edit but I don't agree with it. I think you should really step out of the technical details and focus on what your data is. You are writing the story of your game in a JSON file. Is that really appropriate or convenient? I personally don't think so. I mean, if you're comfortable working with this so far, sure, knock yourself out. Myself, I would use plain and simple text files to hold that dialog (1 line in a file = 1 line of dialog, with name of file = name of NPC or cutscene) They're much more appropriate for storytelling IMHO.
What I mean is, write that dialog in something that is meant for writing. JSON is a format for data-interchange, sure, it's human-readable. That doesn't mean it should be human-written.
Then, when you have your story, if you want your game to consume that data in JSON form, write some kind of wrapper around this bunch of files. Sure, it looks like more work, but I think it's more flexible. Well, that's what I would do anyway. Best of luck.