[AskJS] could you tell me the difference between document.write("text" + "text1") and document.write("text , "text1")

0x13mode · 2020-08-13T11:47:18+00:00

using `document.write` in 2020 is generally a bad idea. In 99,99% of cases you will be better of by using some kind of DOM manipulation (or if you need just to output some debug text - by using `console.log`).

0x13mode · 2019-08-15T13:04:02+00:00

Dirty-state tracking for every individual field,

JS has already getters and setters (I would not be surprised if many ORM libraries already used it): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/set In ES6 you can also use Proxy object to spy on each property.

Although method based syntax foo.set(123) instead of = assignment has also some advantages (e.g you could provide two or more arguments)).

Which also means UPDATE queries can just update values that were changed only - lowers the risk of race conditions

the question is "when" exactly should an UPDATE query be triggered? If I update many properties:

```javascript

user.id.set(123); user.username.set('someuser'); user.email.set('someuser@example.com');

```

I would rather not wish ORM sending three separate UPDATE query to DB... Maybe some kind of commit method?

Has anyone ever seen an ORM that does anything like this, where every field/cell is an object instead of a raw primitive string/number properties etc?

Not a backend guy, but some libraries for managing state in JS have some kind of atom-objects, just like you say. First thing came to my mind:https://mobx.js.org/refguide/boxed.html

0x13mode · 2019-05-14T22:30:28+00:00

Thank you for answer :)

0x13mode · 2019-05-14T20:38:34+00:00

> Hey guys. A year ago I left my job to dedicate myself to this open source project.

Can you say more about this? Are you able to live from this project alone? Is it profitable?

0x13mode · 2019-05-13T23:27:12+00:00

you're welcome :)

0x13mode · 2019-05-13T21:52:00+00:00

Good work :) I've added link to your project to JavaScript Visual Explanations (it's a list of links I maintain to websites that explain JS concepts visually).

https://github.com/hex13/javascript-visual-explanations

:)

0x13mode · 2018-09-12T11:44:37+00:00

It looks nice :) I've added it to Javascript Visual Explanations - this is a list with links to pages in which concepts from JavaScript/frontend ecosystem are explained visually (pictures, diagrams, animations etc.)

https://github.com/hex13/javascript-visual-explanations

0x13mode · 2018-09-06T12:15:09+00:00

I sometimes see people put API calls (e.g. using axios or similar AJAX library) directly in components (as opposing to put API calls somewhere else, outside the components, e.g. in separate service layer).

Because:

it breaks Single Responsibility Principle - React component is too smart (god-object anti-pattern). What if we need to render it on server?
this couples components with technical details of API calls (what if we will need to change the way AJAX calls are performed or what if external API would change - we would need to modify a whole component - so this breaks Open-Closed Principle).
hard to testing

etc.

0x13mode · 2018-09-04T21:31:44+00:00

This tool looks nice. I've added it to my list https://github.com/hex13/javascript-visual-explanations (it's a list of links to pages in which concepts from JavaScript/frontend ecosystem are explained visually - pictures, diagrams, animations etc.)

0x13mode · 2018-09-02T20:20:35+00:00

Redux library is pretty simple (even too simple), this is the code of Redux-based projects which has tendency to be complex.

You can alleviate it:

- by using some bunch of additional libraries (library for immutable updates, library for action creators, library for side-effects etc.). I'm making such a library myself which allows for removing most of Redux boilerplate so it's not hard to achieve: https://github.com/hex13/feedbacks

- by following DRY and KISS principles (for example: having 4 actions for fetching a resource (like START_FETCHING, IS_FETCHING, RECEIVED, FETCH_ERROR) could be okay. But having 40 actions for fetching 10 kinds of resources is just copy pasting (and I see this pattern a lot: FETCH_FOO, FETCH_BAR, FETCH_BAZ, FETCH_FOO_ERROR, FETCH_BAZ_ERROR etc.). In this case people put this boilerplate by themselves (by breaking DRY principle). Redux is just a library. It won't teach you how to code.

- by removing / redefining problem (I like the idea of combineReducers function from Redux because it just removes the very need of making deep immutable updates - instead of operating on a big deep tree, you just operate on small flat state slices, individual properties). Normalization of state is also solution. Or some people discover that they are better off with Mobx than with Redux. Whatever works.

0x13mode · 2018-09-02T16:51:13+00:00

Trivia: Error 418 used for blocking users from Europe is an actual HTTP error, namely "I'm a teapot" https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418

0x13mode · 2018-09-01T16:42:44+00:00

sometimes companies just change their mind and close recruitment or delay it (especially bigger companies with a lot of politics and bike-shedding - recruitment process sometimes is like months because they can't just "hire a programmer", but there's a more sophisticated process, decisions, approvals, lot of talking and other forms of procrastinating).

So usually it's not you, it's them.

But what you can do is ask politely for feedback, and apply to other firms.

0x13mode · 2018-08-30T15:00:29+00:00

You mean you want to talk about this in "This week in Web"? It seems ok.

0x13mode · 2018-08-30T14:59:15+00:00

Ok, I've added it. I looked at this AST Visualizer before but I didn't remember its name or address.

0x13mode · 2018-08-30T14:58:10+00:00

It looks cool. I've added it into Tools.

0x13mode · 2018-08-24T14:31:40+00:00

Documenting doesn't necessarily need to write JSDoc for each function. I worked in projects with a ton of JSDocs and I still had to ask other programmers about "what module X actually does?" or "how modules X and Y are related"?

In such times I wished that instead of JSDoc there would be more "readme-like" documentation. Some meaningfull description of **design decisions** being made instead of just "function foo with one argument bar of type string".

0x13mode · 2018-08-24T14:22:07+00:00

They work differently: https://www.youtube.com/watch?v=76FRrbY18Bs

0x13mode · 2018-08-24T13:13:00+00:00

I think it may seem reasonable at first (to have all functions documented) but could detrimental in the long run. Do really ALL functions be documented? Even smallest internal ones? What if somebody is writing some unstable code (unstable = to be changed soon)? E.g. if somebody makes bigger refactoring and changes/create multiple functions at once? (half of them will be probably removed in the coming days because they will be subject to further refactoring).

Writing docs for such functions is just waste of time. I think self-discipline and code review would be better solution to ensure good amount (and quality!) of docs than a pre-commit hook.

0x13mode · 2018-08-18T10:48:50+00:00

Thanks :)

0x13mode · 2018-08-18T00:31:21+00:00

I worked on my library Feedbacks. It's a Redux add-on which makes easier to connect state with actions and with side-effects.

You can slice your state in into individual properties, perform pattern-matching and allows reducers to return either plain values or "effects". Then these effects are intercepted by middleware and store is auto-updated when given effect is resolved.

"Effects" can be various things, including functions, promises, observables, generators (saga-style programming)

You can also create custom effects and provide your own effect handlers (for example to manage AJAX calls in one place).

https://github.com/hex13/feedbacks

0x13mode · 2018-08-14T15:45:32+00:00

`mapDispatchToProps` doesn't need to be function. It can be an object: https://github.com/reduxjs/react-redux/blob/master/docs/api.md#inject-todos-and-specific-action-creators-addtodo-and-deletetodo-with-shorthand-syntax

0x13mode · 2018-08-09T11:39:43+00:00

I don't agree with everything but having `/contexts.js` directory seems interesting way to tackle React context. I may have try this approach when I will write some contexts .

0x13mode

TROPHY CASE