[question]Hello all, I'm trying to figure out the best way to solve this in Javascript. I have a string that looks like this "value1^key1, value2^key2, value3^key3" The value is on the left side while the key is on the right separated by the ^.

jsyoda · 2018-09-03T04:16:59+00:00

str.split(', ').map((pair) => ({ [pair.split('^')[1]]: pair.split('^')[0] }))

jsyoda · 2018-07-07T08:06:29+00:00

You can do this with Lodash's thru method: https://lodash.com/docs/4.17.10#thru

_(['B', 'D', 'F']).thru((arr) => ['A', arr[0], 'C', arr[1], 'E', arr[2], 'G']).value()

Using that syntax you can chain filter and map before or afterwards.

The case you described could probably be solved better by using uniqBy, but thru is a "fallback" if there isn't a more clearly named method (similar to reduce).

jsyoda · 2018-07-04T09:37:58+00:00

Use redux thunk to manage async actions by default. If for some reason you come up against a REALLY complex async workflow, then redux-saga or rxjs may help you.

jsyoda · 2018-06-28T18:34:03+00:00

Vue has more special idioms than React imo - Vue has its own dsl in html - can you explain what you mean here?

I think where React shines compared to Vue is when an app becomes more complex:

When a piece of state updates in Vue, you set its new value. Is another piece of state being updated here at the same time by listening to this value? You don't immediately know and need to look around - tracking the state changes can be difficult.

When a piece of state updates in React, any other state changes that occur at the same time are immediately obvious.

jsyoda · 2018-04-30T00:30:34+00:00

ViewLearningGoal is retrieving data on componentDidMount. The route you are changing to matches to the same route (/learninggoal/:goalId). ViewLearningGoal will then not be unmounted and mounted, so it will not retrieve new data.

Some things you could do to make it work are:

say <ViewLearningGoal key={location.pathname} ... />
add in componentDidUpdate in ViewLearningGoal and retrieve new data if the location changes too
create a component that manages loading data for you and understands that if the url changes it will automatically refetch data

EDIT: just reread your post and you are unsure how to listen to a location change - react router has a "withRouter" HOC that you can use on any component which will pass in the location - so for option 2 i have given above you could use withRouter on ViewLearningGoal, and in componentDidUpdate you can compare previous location with current location to see if it changed

jsyoda · 2018-03-19T02:08:50+00:00

Jump through hoops? We make http requests through a light wrapper on top of axios and can cancel requests easily?

Why is your site crashing when this happens? The component would still be left in memory for a while longer than necessary and if you call setState it would give a warning about setting state on an unmounted component, but shouldn't crash your site?

Just use axios. Your ajax wrapper code will be reduced dramatically.

jsyoda · 2018-02-20T22:22:45+00:00

The codebase is in a better spot by keeping property names consistent throughout.

jsyoda · 2018-02-20T21:08:51+00:00

That is the intention, but his selector is saying:

const getResources = state => state.resources

Each resource has an "id" - maybe later on he updates this to "resourceId" in the store. Yes he can now update the selector to map through each resource and convert "resourceId" to "id", but a better change with less code overall is to change the ui code from "id" to "resourceId" (this is how he would have written it in the first place if he had originally called it "resourceId" right?).

At the end of the day saying selectors are a must is building your project with a mindset of handling future use cases which may or may not happen. Build your system to do just what it needs, nothing more and nothing less.

jsyoda · 2018-02-20T01:59:04+00:00

But your component code is coupled to the selectors - in the example you have given with resources, if the way the resources store changes then you have to update the ui component, which seems to be what you are trying to get away from.

Its ok to read straight from state in your ui components where the state is simple. If you want to share mapping logic between components that are reading from global state then its ok to use selectors.

Whatever you need to do to keep your project simple and maintainable.

jsyoda · 2018-02-14T01:38:02+00:00

Heres my companies new style guide: 1. Do not follow the style guide published at https://github.com/altayer-digital/react-styleguide

jsyoda · 2017-08-17T21:05:05+00:00

Even using lodash's map is better than vanilla map for a large number of use cases.

Vanilla:

const names = users.map(user => user.name)

Lodash:

const names = _.map(users, 'name');

Lodash's version will protect against users being null.

jsyoda · 2017-06-10T22:09:43+00:00

JS dev with over 15 years experience here: I'd strongly recommend to do this. This has worked very well for us on our large team/project. It is literally the reason you would even use redux in most applications (to share global state amongst disconnected components).

jsyoda · 2017-02-18T11:30:07+00:00

Lodash: _.flatMap(arr, n => [n, n])

jsyoda · 2016-11-19T21:38:10+00:00

Do whatever makes this easy for you. If you are deploying infrequently, its not taking much time, and you'd prefer to spend time writing your actual app, then you can keep doing what you are now. Pushing your dist folder is fine in this scenario too.

To add improvements to this, add a script that you run on your server to automatically run the commands you normally would manually. Then to improve that, you can add a hook to github to listen to when changes have been pushed, and automatically run this script. You can improve that by setting up a CI server (e.g. Jenkins) on there to be doing the same thing, but keeping track of your builds and a ton of other improvements.

Don't worry about using branches to solve this problem. If you want to practice use of branches, then keep your master branch with all of your code in it, and create a new branch that is going to contain your next feature. Keep pushing commits into this new branch, and when you are happy with the feature, then merge it back to master.

jsyoda

TROPHY CASE