New answers tagged json
1
Three things to add to MJ713's answer:
For mutually exclusive options, use if ... elif .... When a match is found, the rest of the conditions are skipped. It may also help to put the order the tests so that the most common case is first and the least common case is last.
dict.setdefault(key, default_value) returns dict[key] if it is in the dict. ...
2
There are a few points in the existing code that I think could be improved.
Confusing function name write_new_json
Naming is important. Good names make your code more readable, and easier to understand. Bad names make it less readable. Names are bad when they don't describe what the thing is/does, or conversely, if they seem to describe something that the ...
1
I'm about kotlin, not about kotson or other kotlin-json libraries.
Also, when writing, I jumped into reification. This isn't really important...
Reified Inline Extension functions
The only reason I'm writing this is because I'm using extension-functions later on and I don't know your kotlin-level. You can skip this if you understand.
You can skip reified ...
2
You have failed to apply TDD, and have over complicated the solution.
Before reviewing your code I completed the challenge myself, which I'll walk you through after reviewing your solution.
Your function resolve_ref
This should be split out into two functions, get_ref and _resolve_ref, having resolve_ref as a convenience to them.
Since you haven't split out ...
2
Your Code seems good.The error channel is a good idea.
Personally, the only change I would suggest is to use the Generator Pattern (something like this https://medium.com/@thejasbabu/concurrency-patterns-golang-5c5e1bcd0833) in the function "parseJSON" it will split the function into 2 and improve readability.
1
As said in my comment, we do not want to execute something without telling it explicitly. Most of the time such programs are built with one class that execute the request and another to model the result.
But let's start by reviewing your code.
The main issue that I see is that you cannot test it without mocking the underlying API. One solution is to ...
1
I ended up using jsonb_build_object (also available as json_build_object):
select jsonb_build_object (
'json_property_1', big_json_field->'json_property_1',
'json_property_2', big_json_field->'json_property_2'
) from table_with_big_json_field
This eliminated the sub-select, and felt a bit cleaner than as-ing every field.
5
I'd recommend (if it isn't already) converting to the type from json to jsonb and adding a GIN index. The documentation below lays it out pretty clear. Good luck!
https://www.postgresql.org/docs/9.4/datatype-json.html
For my recommendation, reason for using jsonb as opposed to vanilla json is that regular json is stored as an exact copy in postgres and you ...
2
If the list never changes once loaded, the data would only ever need to be sorted one time (which ever you prefer as the default). Once sorted, you can just reverse the array as you currently are.
Additionally, if your data comes from a database of sorts, you may not even need to sort on the client at all, you could return an already sorted resultset.
So ...
1
If it works as expected, there's nothing wrong with it.
However to improve the readability, I'd separate the setState call from actual sorting. Also be careful when you change the order state variable and when you use that variable to determine the sort order.
orderUsers() {
if (this.state.order) {
return this.state.users.sort((a, b) => {
if (...
2
Instead of resorting the list in state just store the preferred order in state. Then in render simply sort or reverse the order as needed to present the data. Be sure to use keys that don't change when the order is changed and it'll be quite performant.
Top 50 recent answers are included
