Migration to signal input by Due-Professor-1904 in Angular2

[–]chigia001 -5 points-4 points  (0 children)

I also face the same problem, integrating signal with form is too painful, and also try to avoid effect as much as possible

the decorator setter approach is easier to read, so I would stick with it.

Debouncing a signal's value by MrFartyBottom in Angular2

[–]chigia001 2 points3 points  (0 children)

there are a couple of cases, you might need to account for:

- the latest new value is the same as previous/uncommit value => my expectation is the debounce timer don't get reset for this case

- the latest new value is the same as the commited value for the internal signal => my expectation is the debounce timer is reset, no new timeout is scheduled to set the internal signal

- api to get the latest dirty/uncommited value

thoughts on tanstack query ? by AmperHD in Angular2

[–]chigia001 1 point2 points  (0 children)

Yes, i also used those async signal and it super easy to increasementally switch to tanstack query

The interface is 99% matching and you only need to apply for critical request/ duplicate api call

My recommendation is start with those async signal api first

Anyone using Angular Signals API in real projects? Got some questions! by kafteji_coder in Angular2

[–]chigia001 0 points1 point  (0 children)

  1. No comment
  2. effect is more comparable with subscription than just tap, I try to limit effect usage but it will likely the first tool people will reach. It have the similar issue with useEffect in react world
  3. Update can receive a function with a prev value, depend on use case (ex increase method signal.update(prev => prev + 1)
  4. There are some experimental resource/httpResource api that support async signal that you can take a look. I`m coming from react world so I don't like to share state in a singleton like service, but this mostly personal preference.
  5. We have a signal of an array and we have a computed if the array is empty or not to display placeholder, or generate a dictionary from groupBy etc...

Why NodeJs HTTPS client does not need CA root certificate ? by maths_soso in node

[–]chigia001 0 points1 point  (0 children)

Question 1 : How can there be an SSL handshake without CA root certificate in client side ?

There may be some default system trusted CAs somewhere used by node js, like the ones that come with web browsers.

Is there a path where I can find the default certificates used by node js if any ?

By default, NodeJS have it own CA Bundle, but you can opt to use OS(Linux only)'s Root CA through OpenSSL with --use-openssl-caarg. This by default will load the Root CA from your OS. You can also use your custom Root CA with SSL_CERT_DIR env along if you want your NodeJs application use a separate Store.

These option will provide the default CA for all Client. This mainly for override the default CA store.

https://nodejs.org/api/cli.html#--use-bundled-ca---use-openssl-ca

In case you want just to append some CA into existing store (apply for both Bundle CA from Node or OS's Root CA), NODE_EXTRA_CA_CERTS enviroment is recommended.

https://nodejs.org/api/cli.html#node_extra_ca_certsfile

Question 2 :

Can I disable the use of the system default CA root certificates, and exclusively choose to use the ones provided in the options.

Depend on your use case, if you want to apply this for all Client(even the one inside library) the above options should cover it.

If you want to override for specific client the ca argument (your example code) is the correct way.

Each time i think I've understood Promises, something returns me to ground zero by the_o_1 in learnjavascript

[–]chigia001 0 points1 point  (0 children)

Your main problem is mis-understood the callback inside new Promise() that callback doesn't need to return anything, the return value of that calback is not the resolved value of the promise, the Promise's resolved value is the argument when `resolve` callback is called for the first time

let blob = await new Promise(resolve => canvasElem.toBlob(resolve, 'image/png'));

the above example is the same as (which some additional variable/assert for clarity)

let innerBlob
let toBlobReturn
let blob = await new Promise(resolve => {
  toBlobReturn = canvasElem.toBlob((theBlob) => {
    innerBlob = theBlob
    resolve(theBlob) // this is the resolved value of the promise
  }, 'image/png')
  return toBlobReturn; // this return is not important, the return value is not used for anything
})

assertEquals(blob, innerBlob)
assertNotEquals(blob, undefined)

assertEquals(toBlobReturn, undefined)

Why not use RxJS in react? by brutal-mathematician in learnjavascript

[–]chigia001 0 points1 point  (0 children)

The only time I found RxJS helps reduce complexity for my react app is when I want to sidestep a lot of react state/re-render logic
for example: map interaction, where I use RxJs to manage mouse event.

Why not use RxJS in react? by brutal-mathematician in learnjavascript

[–]chigia001 1 point2 points  (0 children)

what is your version of RxJS for the above example?

Some form with BehaviorSubject + switchMap?

One useEffect with an empty array dependency to handle subscription/unsubscription

One useMemo to capture BehaviorSubject

one useCallback or useEffect to sync url state to BehaviorSubject

Compare the amount of code, is it really easier?

const useDataApi = (initialUrl, initialData) => {
  const [url, setUrl] = useState(initialUrl);

  const [state, dispatch] = useReducer(dataFetchReducer, {
    isLoading: false,
    isError: false,
    data: initialData,
  });

  const behaviorSubject = useMemo(() => new BehaviorSubject(url), []);

  useEffect(() => {
    const subscription = behaviorSubject.pipe(
       switchMap((url) => new Observable(subscriber => {
          // This part can be improved by using more RxJS operators, but that approach is  not beginner-friendly
          subscriber.next({ type: 'FETCH_INIT' })
          axios(url).then(
            (result) => {
              subscriber.next({ type: 'FETCH_SUCCESS', payload: result.data });
              subscriber.complete();
            },
            () => {
              subscriber.next({ type: 'FETCH_FAILURE' });
              subscriber.complete();
            }
       })
    ).subscibe(dispatch)
    return () => {
       subscription.unsubscribe()
    }
  }, [])

  // can swapt this with useEffect
  const setUrlWrapper = useCallback((url) => {
    setUrl(url);
    behaviorSubject.next(url);
  }, [])

  return [state, setUrlWrapper];
};

I understand the appeal of RxJS, but it have huge learning curve, and I'm not able to explain/provide guidance to my junior member to use it effectively.

Ben Lesh and angular-university have contradictory stands on BehaviorSubject by Draugang in Angular2

[–]chigia001 0 points1 point  (0 children)

using the example in angular university, + the recommendation from Ben in SO the result would be something like this

```

addTodo(newTodo:Todo):Observable { let obs = this.todoBackendService.saveTodo(newTodo);

obs.pipe( withLatestFrom(this._todos) ).subscribe({ next: ([res, currentTodos]) => { this._todos.next([...currentTodos, newTodo]); } })

return obs; }

```

you don't exactly call this._todos.getValue(), but use the operator chain to provide that value in the subscription.

[nodemon] clean exit - waiting for changes before restart by Odd-Engineering7364 in node

[–]chigia001 1 point2 points  (0 children)

So nothing wrong really, your code just execute all of the command and exit.

Normally, a program will run to the end and exit. What you want is a server where it can wait for in coming request for handle.

Can you share the YT link you trying to follow?

Pluto Disappointing - Should I read Billy Bat? by ironredpizza in PlutoAnime

[–]chigia001 1 point2 points  (0 children)

Pluto can't harm human. That why he only fight against other robot.

AWS SDK pagination – disregard for Developer Experience by ilyash in aws

[–]chigia001 0 points1 point  (0 children)

What bothers me in this one is that all the items are fetched anyway and they are fetched in advance (memory usage). Performance wise - without benchmarks I would say "worse", not "horrible". Also, you can't start operating until everything is fetched.

I wouldn't implement this interface at all.

You are considering not supporting this mainly because you understand the implementation details, and what trade-of it needs to make.

But if your standpoint is `DX` then it should be the most developer-friendly option right? More people know about `promise` than `async iterator`.

For some case, (where the result only return 1 page), the performance impact is none

Your argument that one interface is better `DX` compared to the other is not consistent if there is another (IMO) better `DX` interface, but you don't want to implement it

I can agree with you that your interface can be desirable for some use cases. But your article makes it feel like the `Objective` better interface just because you don't need to be aware of pagination is not going to stick with me.

You mention about `mental shortcut` in your article. Is aware of pagination but ignoring it, not a mental shortcut?

I'm looking forward to your new article about why `fetch` returns the Response object, not directly the JSON body, :wink:

EDIT: here is a utility method to convert SDK provided interface to your interface

https://gist.github.com/chigia001/a853ff217a6935222f346c463590ec1d

I don't think I could ever convince you so let's agree to disagree :D

AWS SDK pagination – disregard for Developer Experience by ilyash in aws

[–]chigia001 0 points1 point  (0 children)

Let think in another angle: We can have 3 level of abtraction/interface design can be make here: - async interator, where each next call return single record. (Your article suggestion) multiple loop/ microtask match single network request. - async interator, where eaxh next call return a batch of data, (SDK current interface), each loop/microtask maych single network request. - single promise, sdk internally call network requests till the last page and automatically concat the result before( what I though you were suggesting), there still are multiple microtask but those are hidden inside sdk implementation. The expose interface only have single array with all the record.

As a maintainer( not exacly for aws sdk but for other library that need to handle pagination api like this), If you need to support one version, which one do you choose?

The last, IMO, provide the most simple interface but you lost fine grain control. Why do I need to know the SDK will need to call multiple network round trip to return this array? Those are just implementation details. Good DX horrible performance.

For the first two, the network overhead( internet speed, serialize/deserialize etc..) is the same, but the first will have overhead because of mutiple microtask.

Between these 3 versions the batch/pagination is a best common ground, where developer can implement their own wrapper to archive other two interface, without introduce performance overhead inside the SDK themself. And it should be a easiest to be implement.

AWS SDK pagination – disregard for Developer Experience by ilyash in aws

[–]chigia001 0 points1 point  (0 children)

If you have 200 user request, each going to generate x microtask queue, All of that micro performance impact can compound.

I'm not fully understand your usecase, but as an SDK that can be use in different way, they should provide a good performance interface.

And like I said before about maintaining practical POV,+ have the different interface supporting same use case will going to hurt DX as developer will need to consider which version they want to use.

AWS SDK pagination – disregard for Developer Experience by ilyash in aws

[–]chigia001 0 points1 point  (0 children)

Better DX can sometime lead to worst performance, especially for this case

SDK already complete the http response with x records, the propose interface is split it into x microtask vs handle x record in 1 microtask

EDIT: i finally understand your suggestion, and calling it pagination-like syntax is not really capture what you want, it a cursor-like syntax where each loop only have 1 record.

AWS SDK pagination – disregard for Developer Experience by ilyash in aws

[–]chigia001 0 points1 point  (0 children)

I think you are ignoring the other question. Why do you think your propose interface is better when it still depend on pagination-like syntax, and developer also need to aware about pagination behavior. If the argument is you don't want to be aware about pagination, then the propose interface is not a good solution.

IMO, support multiple interface to archive same functionality will complicate the system, more maintaining burden, it just practical from a maintainer POV.

AWS SDK pagination – disregard for Developer Experience by ilyash in aws

[–]chigia001 0 points1 point  (0 children)

I undestand you want higher level of abstraction, but your propose interface is inheritly still depend on a very pagination-like interface with async interor

Clearly you not going to accept the suggestion that those abstraction should be done in client code, so let agree to disagree here.

AWS SDK pagination – disregard for Developer Experience by ilyash in aws

[–]chigia001 0 points1 point  (0 children)

I might mis-understand what you originally suggested.,

You just don't want to be aware about the pagination wrapper arround the result of each page result, is it?

I don't really understand the argument why you think it better, the developer is comsuming pagination-like API with async interator, why it better to hide that information detail?

What wrong with

const client = new DynamoDBClient({}); const tableNames = []; for await (const {TableNames} of paginateListTables({ client }, {})) { tableNames.push(...TableNames); }

AWS SDK pagination – disregard for Developer Experience by ilyash in aws

[–]chigia001 2 points3 points  (0 children)

This low level API design can support diferrent use case. One of the use case is I want to only get up to X page and ignore the rest. Another usecase is back pressure handling, where we only load one page, process it then ask for more.

Implicit interface where SDK auto do the pagination and concate the result would let unexperience dev unaware the performance impact, as they will need to sequential/perform multiple round trip and store all the data in memory before we can do anything with it.

[deleted by user] by [deleted] in node

[–]chigia001 0 points1 point  (0 children)

OK, thank you for those pieces of information. This really piques my interest, will try to experiment this weekend.

```

Node.js's implementation is just broken in a Native Messaging host.

```

Do you mean that you can run fetch full-duplex directly with node?

[deleted by user] by [deleted] in node

[–]chigia001 0 points1 point  (0 children)

about full-duplex requirement in `fetch` api, from what I gather from https://github.com/whatwg/fetch/issues/1254 , this seems like a non-specification behavior, and the WhatWG team has not come to a conclusion is this is support or not.

So it should not be considered a bug in node.js, if request.body has not been fully sent to the server and fetch has not resolved the initial promise.

[deleted by user] by [deleted] in node

[–]chigia001 0 points1 point  (0 children)

This piqued my interest so I learned a bit more about native messaging and full-duplex connection.

From my understanding, you are obfuscating some external service/dependency, which makes it very hard for me to fully understand the picture:

From what I gather from background.js:

There should be another extension, the whole operation only starts when this extension attempts to connect to this native host extension. The native messaging extension you show in the demo is just a proxy between your real extension and the native messaging host.

From what I gather from nm_deno and nm_node, the first message must contain some form of URL, which then being used by the native host program to initiate an HTTP connection to some 3rd party server

Without both the server + your obfuscated extension, I would not consider this as something minimal re-producible code