I'm rewriting some old Chrome extension code while simultaneously trying to learn new ES6 tricks, and I'm running into some design questions.
My goal is to provide a value storage (which is backed by the asynchronous chrome.storage for persistence, but that's outside the scope of the question). What I want is to associate some validation with the values. So, my Storage is a collection of Values, each associated with a validation function.
In my old version, I would just pass a validation function when I instantiate a value, something like this (simplified):
Storage["key1"] = new Value({
validator: ValidatorIsInteger, defaultValue: 0, /* ... */
});
Storage["key2"] = new Value({
validator: ValidatorEnum(["a", "b", "c"]), defaultValue: "a", /* ... */
});
However, I'm trying to rewrite this with Value being a class that can be extended with specific validators, which seemed to be a good idea at the time. Again, simplified:
class Value {
constructor(key, defaultValue) {
this.key = key;
this.defaultValue = defaultValue;
this.set(defaultValue);
}
set(newValue) {
var validationResult = this.validate(newValue);
if (validationResult.pass) {
this.value = newValue;
return newValue;
} else {
throw new RangeError(
`Value ${newValue} for ${this.key} failed validation: ${validationResult.message}`
);
}
}
get() { return this.value; }
// Overload in children
validate(value) {
return {pass: true};
}
}
class IntegerValue extends Value {
validate(value) {
if (Number.isInteger(value)) {
return {pass: true};
} else {
return {pass: false, message: "Value must be an integer"};
}
}
}
So far so good. However, I run into problems when trying to make a parametrized child class:
class EnumValue extends Value {
constructor(key, defaultValue, possibleValues) {
this.possibleValues = possibleValues; // NUH-UH, can't set that before super()
super(key, defaultValue);
}
// Will be called from parent constructor
validate(value) {
if (this.possibleValues.includes(value)) {
return {pass: true};
} else {
return {pass: false, message: `Value must be in [${this.possibleValues}]`};
}
}
}
The problem is in "setting up" the parametrized validator before .set(defaultValue) is called. I see several ways out of this, all of which seems lacking:
Resign, and not use the class-extension-based approach - I want to see if it can be fixed first.
Always trust the default value as a workaround to calling .set(defaultValue) - bad, because I don't want accidentally inconsistent data.
Make .set() asynchronous, giving the constructor a chance to finish before validation is performed - while the persistence backend is asynchronous, the purpose of Storage is, among other things, to provide a synchronous "cache".
Am I failing to see some obvious fix to this approach? If not, and this is simply a wrong tool for the job, how should I re-organize this?
This is the classic problem with calling overrideable methods (validate, via set) from constructors; discussed here (different language, same problem).
Your specific example lends itself to a couple of workarounds, but the general issue remains.
To solve the general problem, I'd set value directly, not via set, and use unit tests to ensure that I didn't create validators that have an invalid default value. That is, after all, a coding error, not a runtime error.
But if you want to keep calling set, a couple of options:
You could have the concept of a Value that has no default value, which might be useful in general anyway. That would solve the problem by letting you have a Value constructor that doesn't expect to receive a default value. You could give a Value a default value after construction via setDefaultValue or similar; that method would validate, but that's fine, because it would be called post-construction in the subclass.
You could give Value a "validating" and "non-validating" state, and have the constructor accept a flag for which state it should start out in. Subclasses would use false if they had special validation behavior, ensure that all their ducks are in a row, and then set the validation state (which would validate).
Related
Is there any point in repeating this pattern for every property in JavaScript?
class Thing {
get myProp() {
return this._myProp;
}
set myProp(value) {
this._myProp = value;
}
}
I understand that getters/setters can be useful if you're doing additional work in the methods, but recreating the basic functionality here seems like needless repetition. If I instantiate, I can still manipulate the backing property (._myProp) directly, so I feel like I could just as easily leave these out and perform my assignment and access in the more typical, ad-hoc fashion.
I suppose you could argue that defining the interface this way (with the underscore-prefixed property name) signals to users that it's not meant to manipulate the property, but that seems like a flimsy reason for potentially dozens of these.
In compiled languages, it's common for people to do this. This is because in those languages, assigning to a field and invoking a setter may be identical to the programmer, but they compile to two completely different operations.
If I wanted to add a side effect for setting a field in a C# class, for example, and that field was being set directly instead of through a setter? Changing it to a setter would cause some issues. I wouldn't have to rewrite any of the consuming code, but I would have to recompile all of it. This is, of course, a huge problem if your public releases are compiled.
JavaScript is subject to no such considerations, though, so making everything into a getter/setter prematurely is kind of silly. If you see someone doing this, more than likely you're dealing with someone who learned the convention from another language and carried it into JavaScript, without thinking a whole lot about why.
Using an accessor property in the fashion you describe (set and retrieve a "background" data property) is virtually semantically identical to using a data property directly. There are some differences: the accessor property will exist on instance's prototype, rather than on the instance directly (though the instance will have the "background" data property), but this won't really affect anything unless you are doing advanced introspection on your class instances.
The only advantage is ease of modifying the code if you want to introduce more sophisticated accessor behavior in the future. If you forsee a need to add accessor behavior, use this pattern to save yourself time in the future.
Property accessors are useful to provide side effects or change original behaviour:
class Thing {
get myProp() {
console.log('myProp was read');
return this._myProp;
}
set myProp(value) {
if (!value)
throw new Error('myProp cannot be falsy');
this._myProp = value;
}
}
There is no point in myProp getter/setter pure abstraction:
class Thing {
get myProp() {
return this._myProp;
}
set myProp(value) {
this._myProp = value;
}
}
If I instantiate, I can still manipulate the backing property
(._myProp) directly,
If private states are what you are looking for you can still use a weak map.
(function(scope) {
"use strict";
const prop = new WeakMap();
scope.Foo = class {
constructor() {
prop.set(this, {});
Object.seal(this);
}
get bar() {
return prop.get(this)._bar;
}
set bar(value) {
return prop.get(this)._bar = value;
}
}
}(this))
const f = new Foo;
f.bar = "bar";
f._bar = "_bar";
console.log(f.bar);
console.log(f._bar);
get and setters are also useful when implementing MVC, you can trigger events on property change.
(function(scope) {
"use strict";
const prop = new WeakMap();
scope.Foo = class {
constructor() {
prop.set(this, {});
prop.get(this)._target = new EventTarget
Object.seal(this);
}
get bar() {
return prop.get(this)._bar;
}
set bar(value) {
prop.get(this)._bar = value;
prop.get(this)._target.dispatchEvent(new CustomEvent('change', {
detail: value
}));
}
addEventListener(event, listener) {
prop.get(this)._target.addEventListener(event, listener)
}
}
}(this))
const f = new Foo;
f.addEventListener('change', function(event) {
console.log("changed!", event.detail);
});
f.bar = "bar";
I have a form field that has the following generic autocomplete:
<generic-autocomplete
v-model='c.heuristicId'
v-on:change='heuristicSelected(i, $event)'
label='Fuente de datos'
:apiFunction='heuristicsFetchFunction'
:disabled='disabled'/>
When saving the form and sending it with this field in blank heuristicIdgets sent as nullwhich is what is desired.
However, when selecting a value from the generic autocomplete and then deleting it, heuristicIdgets sent with the id of the previously selected value.
Inside the function that calls axios I'm logging console.log("heuristicId to be sent: " + campaign.heuristicId);and undefinedgets logged in both scenarios.
EDIT: After inquiring a little bit more I believe that the error might be in one of <generic-autocomplete/>'s computed properties:
isValid: function () {
// this checks that the name in display equals the object selected in
// memory so no invalid labels are displayed while a valid object is 'selected'
let vc = this
let result = false
if (vc.object) {
result = vc.objectName === vc.object.name
console.log('generic-autocomplete#isValid', result)
}
return result
}
An empty vc.objectwill return a falseresult and I haven't been able to satisfactorily handle that.
After logging a really complex control flow I finally got to the point where I knew which properties I had to mutate. However, it turns out that in Vue 2 mutating inline properties is an anti-pattern. The capability of mutating inline props was deprecated from the previous Vue version in order to be consistent with the library's fully reactive paradigm. So what happens is that if you try to mutate an inline property, when the component re-renders, such property will be set back to its default (or previous) value.
This is solved by adding a computed property that's a copy from the property that you want to mutate.
//Somewhere else in the code the property is defined
property: null
//Add the computed property
data: function () {
return {
mutableProperty: this.property,
}
}
This is beginners question..
I have been reading Angular2 documentation, I came across example in
Hierarchical Dependency Injectors chapter where Restore service is used to
make save/cancel functionality available for editing.
This is the service:
export class RestoreService<T> {
originalItem: T;
currentItem: T;
setItem (item: T) {
this.originalItem = item;
this.currentItem = this.clone(item);
}
getItem () :T {
return this.currentItem;
}
restoreItem () :T {
this.currentItem = this.originalItem;
return this.getItem();
}
clone (item: T) :T {
return JSON.parse(JSON.stringify(item));
}
}
I was so excited about it so I tried it myself!
First I'm setting the values like this:
ngAfterContentInit(){
this.metadata = {
languages: this.selected_languages,
countries: this.selected_countries,
international: false
}
}
set metadata(metadata: CvMetadata){
this._restoreService.setItem(metadata);
}
get metadata(): CvMetadata{
return this._restoreService.getItem();
}
After that I'm changing metadata properties values with ngModel
for example: [(ngModel)]="metadata.languages[0]"
The question: For my sruprise When I update the metadata property value with ngModel it works - the currentItem has changed and the orginalItem has not! What I do not understand is how is that possible? I thought that ngModel would use setter for setting the metadata properties. But the setter is called only once when I set the original data. How does the ngModel know that it should change only the currentItem not he originalItem?
Is this the black magic?
I know.. I only need someone to explain this, but unfortunately or fortunately there are only you guys!
Thanks!
RestoreService: it has two functions setter and getter;
setItem (item: T) sets originalItem, clones it and save the clone to currentItem.
getItem() just returns currentItem (the cloned item)
Now, ngModel gets the item metadata in order to get its property languages. So it will get currentItem. When ngModel sets a new property value, it doesn't need to set metadata(). it only need to set languages property inside metadata. So, it will get metadata again and sets the languages property.
Here is a plunker hopefully it will help
Another way of explaining it:
this.metadata = {language:['english']}; // you set metadata, effectively setting originalItem and cloning it to currentItem
this.metadata.languages = ['arabic']; // you get metadata "currentItem", set its property languages. Never actually setting metadata itself
Note on the clone function: the function clone in RestoreService is not cloning the object in a "practical" way. Because it uses JSON parser. See these question for more details and better cloning approaches: 122102, 728360
I am new to es6 and am wondering if this approach is OK.I do not want someone to set properties that I do not want on my object.
export default class User {
static getMembers() {
return ['username','email','fullname','birthdate'];
}
constructor(props) {
Object.keys(props).forEach((p)=>{
if (User.getMembers().includes(p)) this[p]=props[p]
});
Object.defineProperty(this,"username",{writable:false});
Object.defineProperty(this,"email",{writable:false});
}
any other approaches?
With your code as shown, you can't set any value for username or email. They'll always be undefined, as you've made them read-only and haven't assigned them a value. You also haven't done anything to prevent code with access to one of these objects setting a completely arbitrary property:
let u = new User();
x.anythingIWant = 42;
If you want to prevent code from adding properties to an object, you can do that with Object.seal (ref: MDN, spec), which prevents new properties being added and makes it impossible to re-define existing properties. So:
export default class User {
constructor() {
// ...create your desired properties
// Seal the object
Object.seal(this);
}
}
And if you also want to make username and email read-only, you'd also include the Object.defineProperty calls you have (before the Object.seal). Just make sure you assign them values first, as once you've done that defineProperty and Object.seal, you can't change them anymore.
I think I'd probably approach using that array of whitelisted properties slightly differently as well, by just looping through the array.
So:
export default class User {
static getMembers() {
return ['username','email','fullname','birthdate'];
}
constructor(props) {
// Create the properties
User.getMembers().forEach((name) => { this[name] = props[name]; });
// Make sure username and email have a value, because we won't
// be able to change it in a moment
// ...
// Make username and email read-only
Object.defineProperty(this, "username", {writeable: false});
Object.defineProperty(this, "email", {writeable: false});
// Seal the object
Object.seal(this);
}
}
I'm trying to wrap a cookie in a computed observable (which I'll later turn into a protectedObservable) and I'm having some problems with the computed observable. I was under the opinion that changes to the computed observable would be broadcast to any UI elements that have been bound to it.
I've created the following fiddle
JavaScript:
var viewModel = {};
// simulating a cookie store, this part isnt as important
var cookie = function () {
// simulating a value stored in cookies
var privateZipcode = "12345";
return {
'write' : function (val) { privateZipcode = val; },
'read': function () { return privateZipcode; }
}
}();
viewModel.zipcode = ko.computed({
read: function () {
return cookie.read();
},
write: function (value) {
cookie.write(value);
},
owner: viewModel
});
ko.applyBindings(viewModel);?
HTML:
zipcode:
<input type='text' data-bind="value: zipcode"> <br />
zipcode:
<span data-bind="text: zipcode"></span>?
I'm not using an observable to store privateZipcode since that's really just going to be in a cookie. I'm hoping that the ko.computed will provide the notifications and binding functionality that I need, though most of the examples I've seen with ko.computed end up using a ko.observable underneath the covers.
Shouldn't the act of writing the value to my computed observable signal the UI elements that are bound to its value? Shouldn't these just update?
Workaround
I've got a simple workaround where I just use a ko.observable along side of my cookie store and using that will trigger the required updates to my DOM elements but this seems completely unnecessary, unless ko.computed lacks the signaling / dependency type functionality that ko.observable has.
My workaround fiddle, you'll notice that the only thing that changes is that I added a seperateObservable that isn't used as a store, its only purpose is to signal to the UI that the underlying data has changed.
// simulating a cookie store, this part isnt as important
var cookie = function () {
// simulating a value stored in cookies
var privateZipcode = "12345";
// extra observable that isnt really used as a store, just to trigger updates to the UI
var seperateObservable = ko.observable(privateZipcode);
return {
'write' : function (val) {
privateZipcode = val;
seperateObservable(val);
},
'read': function () {
seperateObservable();
return privateZipcode;
}
}
}();
This makes sense and works as I'd expect because viewModel.zipcode depends on seperateObservable and updates to that should (and does) signal the UI to update. What I don't understand, is why doesn't a call to the write function on my ko.computed signal the UI to update, since that element is bound to that ko.computed?
I suspected that I might have to use something in knockout to manually signal that my ko.computed has been updated, and I'm fine with that, that makes sense. I just haven't been able to find a way to accomplish that.
sigh, I found someone with my exact same problem
If dependentObservables don't notifySubscribers on write, why do they
even bother to do it on read? They get added to the observables list
and subscribed to, but then they never trigger on updates. So what is
the point of subscribing to them at all?
Ryan Niemeyer answers:
I think that for your scenario, dependentObservables may not be the
right tool for the job. dependentObservables are set up to detect
dependencies in the read function and re-evaluate/notify whenever any
of those dependencies change. In a writeable dependentObservable, the
write function is really just a place to intercept the write and allow
you to set any observables necessary, such that your read function
would return the proper value (write is typically the reverse of read
in most cases, unless you are transforming the value).
For your case, I would personally use an observable to represent the
value and then a manual subscription to that observable to update the
original value (the one that you may not have control over).
It would be like: http://jsfiddle.net/rniemeyer/Nn5TH/
So it looks like this fiddle would be a solution
var viewModel = {};
// simulating a cookie store, this part isnt as important
var cookie = function () {
// simulating a value stored in cookies
var privateZipcode = "12345";
return {
'write' : function (val) {
console.log("updated cookie value with: " + val);
privateZipcode = val;
},
'read': function () {
return privateZipcode;
}
}
}();
viewModel.zipcode = ko.observable(cookie.read());
// manually update the cookie when the observable changes
viewModel.zipcode.subscribe(function(newValue) {
cookie.write(newValue);
});
ko.applyBindings(viewModel);
That makes sense and its somewhat simpler to use. Overall I'm not sure how great of an idea it is to treat a cookie as an observable since the server could edit it in an ajax request, etc.
Try making your internal privatezipcode an observable. See here: http://jsfiddle.net/KodeKreachor/fAGes/9/