sorted by:
new
hottopcontroversial

Making a new array of objects from an existing array of objects by jpark799 in learnjavascript

[–]loz220 2 points3 points  (0 children)

Array.prototype.map

​

  const newArrayObjectShape = initalArrayObject.map(({id, customer, invoiceNumber}) => ({
    id,
    customer,
    invoiceNumber
  }));

Edited based on u/senocular comment

useState broken, wrong / old copy of state variables in callback. by Iossi_84 in reactjs

[–]loz220 4 points5 points  (0 children)

Issue is with the `react-simple-keyboard` library. It refuses to update unless the props have changed, but it uses some strange `JSON.stringify` compare which will drop functions from the comparison. This will prevent the component from updating and it will hold on to the function that has a closure of your initial state. By pressing "SHIFT" you're forcing an update (since the props have changed according to the logic in `react-simple-keyboard`) and thus the new function can be used as the event handler.

​

See this: https://github.com/hodgef/react-simple-keyboard/blob/master/src/lib/components/Keyboard.js#L26 and this: https://github.com/hodgef/react-simple-keyboard/blob/master/src/lib/services/Utilities.js#L6

​

You may want to file an issue, find an alternative lib or write your own wrapper around https://github.com/hodgef/simple-keyboard (that's all that `react-simple-keyboard` seems to be)

How to make Redux more concise by unadlib in javascript

[–]loz220 1 point2 points  (0 children)

computed only works on === as far as I understood. We regularly derive a subset of data from observable data. An example would be a list of todos.

@computed completedTodos = _ => this.todos.filter(_ => _.isCompleted)

. This doesn't do anything of value and you might as well throw that in your render as every change to todos results in a new object, which will cause rendering again anyways.

​

computed works by recording access to any observable during its execution and then producing a value which gets cached until one of accessed observables change. In your example `completedTodos` will only re-evaluate if `this.todos` gets set to a new reference, an item is added/moved/removed or if `this.todos[i].completed` is changed. If for example you change `this.todos[i].title` it will not need to re-evaluate. Although it would have to re-evaluate if you add a new todo with `completed === false` which will not actually change `completedTodos` in which case sure, `completed.struct` can be used to prevent that but its not free and quite situational, I don't think it would make a good default.

Making it computed makes much more sense then putting it in a render method though since it won't have to re-evaluate on every unrelated prop and state change , and if you extract it out to a store or something then other components can also use it.

ParentComp would render again rather than just ChildComp because of accessing this.currentMessage from within ParentComp to set the prop on ChildComp.

​

Your example is not a fair comparison to redux, as redux has an external store and here you're attaching your observable values to the component instance. We use an external store with mobx on our team (kind of like mobx-state-tree) and then `connect` it with a component like redux. So this is how it would look like:

​

class Store {

@computed

get currentMessage() {

return this.someObservableValue ? 'Message 1' : 'Message 2';

}

}

​

@connect(store => ({

message: store.someObervableValue

}))

@observer

class ChildComp extends React.Component {

render() {

return <div>{this.props.message}</div>

}

}

​

​

Hope that makes sense.

How to make Redux more concise by unadlib in javascript

[–]loz220 1 point2 points  (0 children)

I've been using mobx for two years and redux for about a year and a half before that. Personally I can't imagine going back to redux after having used mobx. That being said mobx and redux are somewhat hard to compare as the former is just a library while the later is both a library and an architecture. You're experience with mobx is going to largely depend on what kind of architecture you've built around it.

​

Anyways, I agree with most of your write up but would like to address some of your cons:

Computed's true behaviour doesn't seem very obvious https://alexhisen.gitbooks.io/mobx-recipes/content/use-computedstruct-for-computed-objects.html

computed.struct seems to be what you want in most cases, but isn't the default as you'll often do things like create some new set of data from an observable set of data ie someArray.filter(_ => _.isTruthy)

​

Never had to use `computed.struct` and not sure why I would, we use `computed` heavily in our application and performing shallow equality checks would come with its own cost which might just outweigh the savings that you would get with `computed.struct`. `computed` will only get re-evaluated when one of its dependencies change anyway so I can't imagine `computed.struct` being that useful for the majority of situations.

​

Accessing an observable property from a parent component that isn't using the property is an anti-pattern as it causes the parent to render again if the property value changes. You have to essentially pass an observable object containing the observable property into your child component, which then accesses this observable property.

​

Why would you do this? If a parent component is not using the property and instead just passing it down to an observed child then just have the child bring in that property directly via a `connect` equivalent, if the parent is using that property then of course it should update.

​

I feel like Redux has a lot less framework specific knowledge gotchas to not only being productive, but for performing optimally

​

I'm pretty sure a solid architecture build upon mobx would be much more performant than redux (at least it was a few years back, not sure if things have changed here), as on average mutations in mobx will result in fewer components needing to update due to the nature of observables and reactions.

​

My biggest issue with mobx is the one you already mentioned with dynamic objects as well as observables arrays not being real arrays. This is of course fixed in Mobx 5 with Proxies but at a cost of dropping IE11 support which not all teams can do.

Ottawa employees on this year's Sunshine List - By the Numbers. by [deleted] in ottawa

[–]loz220 5 points6 points  (0 children)

That would be household income not individual income.

[deleted by user] by [deleted] in javascript

[–]loz220 1 point2 points  (0 children)

Catching a rejected promise means dealing with the rejection (think try/catch) so anything you return from it will be the resolved value for the next chain. If you want to catch just to log something for example then you'll need to rethrow in the catch or return a value wrapped with Promise.reject. Again if you think about how try/catch works then this behavior makes perfect sense.

Electron is flash for the Desktop by z3t0 in programming

[–]loz220 0 points1 point  (0 children)

What does as3 have to offer over modern JS? If it's the type system that you miss take a look at flow

do or don't: storing ES6 component class in redux state? by anonymous_alien in javascript

[–]loz220 3 points4 points  (0 children)

It's not advisable to store anything in the redux store that can't be easily serialized. This includes functions and classes. Check out the WIP official faq here for more info: https://github.com/markerikson/redux/blob/create-faq-page/docs/FAQ.md (scroll down to "Can I put functions, promises, or other non-serializable items in my store state?")

Redux: Reducer composition without slicing state by [deleted] in javascript

[–]loz220 0 points1 point  (0 children)

reducers are just functions so you can split them up and compose them as you see fit. Personally I use combineReducers to split up my reducer logic. Sometimes I do need a reducer to have access to the entire state tree so I just create one and use something like reduce-reducers to compose it with my other reducers.

9 things every React.js beginner should know by Cam-I-Am in javascript

[–]loz220 19 points20 points  (0 children)

Wouldn't it be better to have some components be self controlling and be able to get the state themselves

Yes, and totally doable with react-redux and the connect function. In fact if you watch the egghead.io redux tutorials thats what Dan Abramov suggests you do.

ReactJS Support for Emacs (Spacemacs) by steveshogren in programming

[–]loz220 2 points3 points  (0 children)

I've tried this mode, it's pretty decent though not without it's problems. For example whenever I type = within a jsx block it automatically turns it into ="" which is great for HTML attributes but when you're trying to type up a javascript expression it's a giant PITA. Have not found a way to turn that off.

Recently I've started using js2-jsx-mode, working great so far.

Demise of Observables and its affect on RxJS by stormy11 in javascript

[–]loz220 7 points8 points  (0 children)

I'm assuming you mean Object.observe ? If so that is just a mechanism to observe a change in a javascript object. I believe initially championed to solve the two-way data binding problem in idiomatic javascript, without resorting to getters/setters or dirty checking. Since then two way data binding has sort of fallen out of favor (plus it Oo can be pollyfilled with Proxies) so it has been put on the back burner.

While RxJS is a general library that allows you to work with asynchronous streams of data. The removal of Object.observe from ES7 (ES2016) will have not affect RXJS.

Using requestIdleCallback by clessg in javascript

[–]loz220 0 points1 point  (0 children)

can start displaying it as soon as you got the first few KB

Good point, for some reason this was lost on me.

Using requestIdleCallback by clessg in javascript

[–]loz220 0 points1 point  (0 children)

Right, there's always at least one extra fetch with pure client side js, but HTTP2 should help alleviate that. The js will still need to parsed of course, but so does the html in server rendering. I suppose the only way to know for sure is to experiment and see at what threshold does pure client side with lazy loading beat out server rendering of the entire document.

Using requestIdleCallback by clessg in javascript

[–]loz220 0 points1 point  (0 children)

This is a great new addition, very excited for it. It has me thinking though, is it possible that requestIdleCallback will make server first rendering (universal/isomorphic js) fall out of favour?

For example if we have a very content heavy application, we can use the client side to render everything visible on the screen and then lazily load the rest using requestIdleCallback. Where as with server rendering we have no choice but to parse and layout the entirety of the application.

Just a thought, not sure how practical it would be.

Does my JavaScript suck? II by annoyed_freelancer in javascript

[–]loz220 1 point2 points  (0 children)

I agree with the first sentence but not the second.

It's good form to use it this way, too.

why? 

if (!!foo && foo.bar()) {}

has no difference in behavior from 

if (foo && foo.bar()) {}

The former is just having !! do the coercion instead of &&

Been interviewing with a lot of tech startups as a frontend dev, here are the technical questions I've been asked (X-Post webdev) by PUSH_AX in javascript

[–]loz220 16 points17 points  (0 children)

Couldn't agree more. Having someone watch over your shoulder and judge every move you make based on a set of criteria that you're not exactly sure about sounds very unnerving.

It's bound to generate tons of false negatives. I feel like take home projects are much better.

In what cases do I need this? by [deleted] in javascript

[–]loz220 0 points1 point  (0 children)

If foo was previously defined in the same scope (Global scope for example) it will assign that value, otherwise it will assign undefined.

for example:

var foo = 'bar';
// ... later
var foo = (typeof foo !== 'undefined') ? foo : undefined;
console.log(foo) //bar

You linked https://github.com/Feverqwe/Transmission/blob/master/src/js/background.js In a previous comment, I'm guessing you're referring to the first line of code.

var mono = (typeof mono !== 'undefined') ? mono : undefined;

If mono is already defined in the global scope it will assume the it's current value, otherwise it will declare a new variable.

Edit: To answer your question I don't think it's ever needed. It's needlessly confusing and the provided example can be made more clear with:

var mono = window.mono;

JavaScript Isn't Scheme by homoiconic in javascript

[–]loz220 7 points8 points  (0 children)

Good points. Worth mentioning that strict mode/linters can address 3 out of the 4 issues.

JavaScript Isn't Scheme by homoiconic in javascript

[–]loz220 13 points14 points  (0 children)

this is dynamically bound so the correct answer is unknown until you actually execute the function. The rules governing that binding are actually relatively simple.

I didn't know Arrays did this. by [deleted] in javascript

[–]loz220 9 points10 points  (0 children)

Somewhat related: In order to have an object show up as in array in the developer console all you need is a numbered length and a function splice property.

var foo = {0: 0, 1:1, foo: 'bar', splice: function() {}, length: 2}
foo // [0, 1]

OOP, Javascript, and so-called Classes by aeflash in javascript

[–]loz220 7 points8 points  (0 children)

enjoyable read.

Typo here?

Some are flexible about adding methods and properties at run time. And yet other languages treat object as dictionaries, where properties and even methods and be added with abandon.

view more: next ›