In immutable.js what is the equivalent of an empty object?
My code is:
let iState = fromJS(state)
iState = iState.setIn(['ui', 'drafts'], {})
return iState.toJS()
But I think I should not use {} when using setIn. Please advise what I should use.
The best 'empty' data structure to use will depend on your use case (and I highly recommend looking at the other data structures and use their advantages) but for the most common interface/expected behavior and structure - Record will be the closest analog. That said, I also recommend looking into the Map data structure as it has a bit more functionality baked in than Record that you may find you need.
Related
JOI 10 is used to validate calls against an API. I now want to sanitize many (but not all) of the strings that are contained in the JSONs before validating them, namely filter out certain characters. I know that this would be an easy task with a recent JOI version as there's the custom() method that I could use. Unfortunately updating JOI is not an option and so I am currently looking for an elegant way to solve this, preferably using the JOI schemas.
I found that there is the extend() function which allows me to define custom types/validations. However, I am not entirely sure how to use it and where to put the code. Also, I am not sure if it's suited to alter the string at all. Can I use extend() to achieve this? If not, is there another way to do this within JOI?
OK, it's actually pretty easy.
const customJOI = JOI.extend({
name: "sanitizedString",
base: JOI.string(),
pre(value: string, state: any, options: any) {
return value.replace(/yourregex/, "");
}
});
and just use customJOI instead of JOI where the sanitization is needed with .sanitizedString() instead of .string().
In the excellent mvvmcross-library I can use RIO binding to prevent unreadable code:
public INC<String>Title = new NC<String>();
Then I can read and write values using Title.Value. Makes the models much more readable.
Normally, this property would be written as:
private string _title;
public string Title
{
get { return _title; }
set
{
_title = value;
RaisePropertyChanged("Title");
}
}
But when I want to use sqlite-net, these fields cannot be streamed to the database because they are not basic types with a getter and setter.
I can think of a few options how to get around that:
Make a new simple object that is similar to the model, but only with
the direct db-fields. And create a simple import-export static
method on the model. This also could prevent struggling with complex
model-code that never needs to relate to the actual database.
Make sqlite-net understand reading NC-fields. I read into the code of the mapper, but it looks like this is going to be a lot of work because it relies on the getter-setter. I did not find a way to insert custom mapping to a type, that could be generic.
Remove RIO and just put in all the code myself instead of relying on RIO.
Maybe someone has some advice?
Thanks Stuart. It was exactly my thought, so I did implement it that way: my (DB) Models do not contain RIO. Only my viewmodels do, and they reference a Model that is DB-compatible.
So, for posterity the following tips:
- Do not use RIO in your models that need to be database-backed.
- Reference models in your viewmodels. In the binding you can use the . (dot) to reference this model.
This keeps them nicely separated. This gives you also another advantage: if you need to reuse a model (because the same object might be displayed twice on the screen), but under different circumstances, it is much easier to handle this situaties to find this already instantiated model.
I'm working in Python here (which is actually pass-by-name, I think), but the idea is language-agnostic as long as method parameters behave similarly:
If I have a function like this:
def changefoo(source, destination):
destination["foo"] = source
return destination
and call it like so,
some_dict = {"foo": "bar"}
some_var = "a"
new_dict = changefoo(some_var, some_dict)
new_dict will be a modified version of some_dict, but some_dict will also be modified.
Assuming the mutable structure like the dict in my example will almost always be similarly small, and performance is not an issue (in application, I'm taking abstract objects and changing into SOAP requests for different services, where the SOAP request will take an order of magnitude longer than reformatting the data for each service), is this okay?
The destination in these functions (there are several, it's not just a utility function like in my example) will always be mutable, but I like to be explicit: the return value of a function represents the outcome of a deterministic computation on the parameters you passed in. I don't like using out parameters but there's not really a way around this in Python when passing mutable structures to a function. A couple options I've mulled over:
Copying the parameters that will be mutated, to preserve the original
I'd have to copy the parameters in every function where I mutate them, which seems cumbersome and like I'm just duplicating a lot. Plus I don't think I'll ever actually need the original, it just seems messy to return a reference to the mutated object I already had.
Just use it as an in/out parameter
I don't like this, it's not immediately obvious what the function is doing, and I think it's ugly.
Create a decorator which will automatically copy the parameters
Seems like overkill
So is what I'm doing okay? I feel like I'm hiding something, and a future programmer might think the original object is preserved based on the way I'm calling the functions (grabbing its result rather than relying on the fact that it mutates the original). But I also feel like any of the alternatives will be messy. Is there a more preferred way? Note that it's not really an option to add a mutator-style method to the class representing the abstract data due to the way the software works (I would have to add a method to translate that data structure into the corresponding SOAP structure for every service we send that data off too--currently the translation logic is in a separate package for each service)
If you have a lot of functions like this, I think your best bet is to write a little class that wraps the dict and modifies it in-place:
class DictMunger(object):
def __init__(self, original_dict):
self.original_dict = original_dict
def changefoo(source)
self.original_dict['foo'] = source
some_dict = {"foo": "bar"}
some_var = "a"
munger = DictMunger(some_dict)
munger.changefoo(some_var)
# ...
new_dict = munger.original_dict
Objects modifying themselves is generally expected and reads well.
Would it be possible to serialize a model object into a query string?
I've no idea if this is even possible, but if not, what is the best way to do this?
<% Html.RenderAction("Grid", "Grid", new { gridModel= ViewData["model"]}); %>
The Model is containing ca 20 properties, and creating the querystring with them in individually would make it a pain to work with and it would look really ugly. so what alternatives do I have?
To answer directly, you could use something like JSON.NET to serialize it to ASCII and then base64 encode it.
However, there are very real limits on how much data you can include in the query string and I'd hesitate to do this.
The closest thing I can think of would be to create a GUID, use that GUID as a key to store the object in Session, then pass the RenderAction the GUID. That action would pull the object out of the Session and then remove it from the Session.
Quick pseudocode (not guaranteed to even compile, much less work)
var _requestKey = Guid.NewGuid();
Session[requestKey] = gridModel;
Then on the other side:
var gridModel = Session[requestKey] as GridModelType;
Session[requestKey] = null;
I ended up using Form for this. Wasn't as pretty and nice as I wanted, but as far as I understand the only good way I could do it.
I wonder if you think that there is a need to refactor this class.( regarding separation of concern)
publi class CSVLIstMapping<T>
{
void ReadMappingFromAttirbutes();
void GetDataFromList();
}
ReadMappingFromAttributes - Reads the mapping from the type T and stores it in the class. Has a name of the list to use and a number of csvMappingColumns which contains the name of the property to set the value in and the name of csvcolumns.
GetObjectsFromList - uses a CVSListreader ( which is passed in via the constructor) to get the data from all row's as KeyValuePair ( Key = csvcolumnName , value = actually value) and after that it uses the mappinginformation( listname and csvMappingColumns ) to set the data in the object.
I cant decide if this class has 2 concerns or one. First I felt that it had two and started to refactor out the conversion from rows to object to another object. But after this it felt awkward to use the functionality, as I first had to create a mappingretriver, and after that I had to retrive the rows and pass it in together with the mapping to the "mapper" to convert the objects from the rows
/w
Sounds like two concerns to me: parsing and mapping/binding. I'd separate them. CSV parsing should be a well-defined problem. And you should care about more than mere mapping. What about validation? If you parse a date string, don't you want to make sure that it's valid before you bind it to an object attribute? I think you should.
Rule of thumb: if it's awkward, it's wrong.
I have to say I'm finding it hard to understand what you've written there, but I think it's likely that you need to refactor the class: the names seem unclear, any method called GetFoo() should really not be returning void, and it may be possible that the whole ReadMappingFromAttribute should just be constructor logic.