Develop Reference

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

Create navigable tree from csv of path names [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 2 years ago.
Improve this question
we are struggling with a large migration project currently and are on the last leg of putting together the user interface.
I have a list of effectively folder paths from the old system like so:
/Programme1/Project1/WorkPackage1/Resources
/Programme1/Project1/WorkPackage1/Plans
/Programme1/Project1/WorkPackage1/Finance
/Programme1/Project1/WorkPackage1/Reporting
/Programme1/Project1/WorkPackage1/Documents
/Programme1/Project1/WorkPackage2/Resources
/Programme1/Project1/WorkPackage2/Plans
/Programme1/Project1/WorkPackage2/Finance
/Programme1/Project1/WorkPackage2/Reporting
/Programme1/Project1/WorkPackage2/Documents
/Programme1/Project2/WorkPackage1/Resources
/Programme1/Project2/WorkPackage1/Plans
/Programme1/Project2/WorkPackage1/Finance
/Programme1/Project2/WorkPackage1/Reporting
/Programme1/Project2/WorkPackage1/Documents
/Programme2/Project1/WorkPackage1/Resources
/Programme2/Project1/WorkPackage1/Plans
/Programme2/Project1/WorkPackage1/Finance
/Programme2/Project1/WorkPackage1/Reporting
/Programme2/Project1/WorkPackage1/Documents
/Programme2/Project1/WorkPackage2/Resources
/Programme2/Project1/WorkPackage2/Plans
/Programme2/Project1/WorkPackage2/Finance
/Programme2/Project1/WorkPackage2/Reporting
/Programme2/Project1/WorkPackage2/Documents
/Programme2/Project2/WorkPackage1/Resources
/Programme2/Project2/WorkPackage1/Plans
/Programme2/ Project2/WorkPackage1/Finance
/Programme2/Project2/WorkPackage1/Reporting
/Programme2/Project2/WorkPackage1/Documents
Currently these are in a csv, we need to be able to create a navigable object that a user can use to navigate through to find relevant documentation.
We have a number of issues:
There are 114000+ rows in the csv
We know the max number of subfolders and it's large (too many to code manually!).
There are special characters in the list, including umlauts, french accented chars + greek alphabet chars...
A fair number (2000+) rows of the list are longer than 400 characters..
We're limited also to what tools we can use. We've been playing with json/jquery/jstree/javascript/excel-vba and have had some success, but its been painful.
If anyone out there has had a similar challenge and any success I'd be interested in finding out how you went about it!
Thanks for looking.
Fohls

If I were you I'd transform the flat paths from the csv into a tree structure and store it in a database. This is essentially the information you have but without the redundancy in the csv. From there it's pretty straight forward transform it to a presentation form. Jstree is one good option. Shouldn't take long to get that up and running.

The solution was to create a mini db (1 table) containing all the folder paths in a single column, plus their parent and whether they had children (figured out using VBA...)
We then used a REST call to pull back the paths/nodes related to the node we clicked on and then pushed those into a function in javascript on the page to then convert to JSON and then use them in JSTREE!
Painful but it works... Now to work out how to make the throbber display when we click....

short html/css syntax: <div a b c></div> - any reasons why not? [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 6 years ago.
Improve this question
I would like to discuss the way how I currently like to write html in cases when standard compliant syntax and semantics are not so important, like in a phonegap app (my principle then: if it works on all devices it's OK)
I make my html as short as possible in the following way:
<i x y z="0"><b a b c></b></i>
with css:
[x]{something}
[y]{something}
[z="0"]{...}
...
So this is instead of the normal class syntax which is to devious for my liking.
the pros for me:
it's short and requires less time to type code
combined with javascript it works nice to for instance toggle attribute values and then make styling dependent on the values
I guess the html is faster to process by the machine because it's shorter but I'm not sure about css, maybe css classes are processed much faster than custom attributes? < please comment
haven't found a case where it doesn't work
I would like to know whether there are any good reasons not to do this from a performance/technical perspective. But not from a 'code must be readable' perspective.

The HTML spec doesn't say what the browser should do if it encounters an invalid attribute. At worst the only thing that'll happen is your code will fail validation.
I guess the html is faster to process by the machine because it's shorter
Code that fights the spec/parser will almost invariably be slower than code that doesn't. This is because browser developers have to write special handling for non-conforming code since HTML is intended to be backwards compatible all the way to the very beginning. Saying "it's faster" because you shaved off a few bytes on an attribute name is a unfounded statement and bound to get you a room full of laughter in a code review.

when standard compliant syntax and semantics are not so important, like in a phonegap app
And what about if phonegap gets an update breaking your code because your are not standard conform?
it's short and requires less time to type code
In the beginning it might be, but it decreases maintainability drastically. So if you need to change something after a while, coding will become really slow, because you will have problems understanding your own code.
I guess the html is faster to process by the machine because it's shorter but I'm not sure about css, maybe css classes are processed much faster than custom attributes?
There won't be a noticeable difference for parsing.
A good coding style is a style that will allow you to add another person to your team and the effort to understand your code is as low as possible.

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.