I'm using the browser language detector for i18next.
I'm using the default precedence, which is
['querystring', 'cookie', 'localStorage', 'navigator', 'htmlTag', 'path', 'subdomain']
I want to be able to set localStorage.i18nextLng dynamically, and have i18next update the language, but still respect the detection precedence.
Is there a way to tell i18next to run the language detector again? Or is there another way to accomplish this?
You can change the local storage value and then trigger i18next.changeLanguage() to change on runtime.
Related
Sonar displays Rename function to match the regular expression ^[a-z][a-zA-Z0-9]*$ for any composable Jetpack Compose function starting with an uppercase. Is it possible to somehow suppress those logs?
Do not use the platform for Compose apps for now, since clearly, the developers have not yet adapted to the framework. Compose encourages you to use function names starting with an uppercase letters, but they are still 'functions', which traditionally start with a lowercase letter and hence the warning.
Unless they provide a way to manipulate the logs explicitly (check their FAQs), there's not much you can do, other than temporarily stopping their product's use in files containing #Composable definitions.
I am not sure if that is the best solution but at this moment I have not found better.
Just simply disable the inspection (alt+enter) at the warning and you should see the option.
I am looking forward for better idea.
In your Sonarqube Quality Profiles, change the kotlin:S100 rule ("Method names should comply with a naming convention") from
^[a-z][a-zA-Z0-9]*$
to the "Sonar way":
^[a-zA-Z][a-zA-Z0-9]*$
Just implemented a custom cache store based on the official existing RocksDb one for a different backend store.
That leads me to a number of concerns/questions:
Found out the hard way that PersistenceContextInitializerImpl is auto-generated and had added an import from Eclipse to resolve the issue. Now I have to leave it non-imported and showing as an error in Eclipse, is there a best practice way to handle this?
Why is RocksDBDbStoreTest#testSegmentsRemovedAndAdded call when segmented is false, since this calls removeSegments that contractually should not be called if not segmented?
Same class, why is buildConfig numSegments set or larger than 1 for non-segmented test cases?
Any example of store implementing the NonBlockingStore transactional methods? Mostly wondering to make sure that all calls are from the same thread?
Wanted to disable the compatibility test, since not supported in prior versions. Changed group to unstable or manual and would always still get called, which doesn't seem to match documentation. What is the right way to disable it from build time run?
Are there any kind of performance/stress tests for persistence store that can be executed or adapted?
Found out the hard way that PersistenceContextInitializerImpl is auto-generated and had added an import from Eclipse to resolve the issue. Now I have to leave it non-imported and showing as an error in Eclipse, is there a best practice way to handle this?
There should be a way to have it run the annotation processor. We use IntelliJ and it works fine OOTB.
Why is RocksDBDbStoreTest#testSegmentsRemovedAndAdded call when segmented is false, since this calls removeSegments that contractually should not be called if not segmented?
This is just a side effect of having a parameterized test like that. In actual runtime it won't be invoked. You can just have the test ignore it if it is segmented.
if (segmented) return;
Same class, why is buildConfig numSegments set or larger than 1 for non-segmented test cases?
Infinispan data container is always segmented when running any of the cluster modes. The store however is not required to be segmented in those cases. If the store is not segmented you can ignore any segment parameters as documented.
Any example of store implementing the NonBlockingStore transactional methods? Mostly wondering to make sure that all calls are from the same thread?
You can see some at https://github.com/infinispan/infinispan/blob/main/persistence/jdbc/src/main/java/org/infinispan/persistence/jdbc/stringbased/JdbcStringBasedStore.java#L724. The methods can and will be invoked from different metehods, thus why it stores a Map keyed by the Transaction.
Wanted to disable the compatibility test, since not supported in prior versions. Changed group to unstable or manual and would always still get called, which doesn't seem to match documentation. What is the right way to disable it from build time run?
Not sure I understand the question. For your store you shouldn't need any compatibility test, so just don't copy that test file.
Are there any kind of performance/stress tests for persistence store that can be executed or adapted?
We have https://github.com/infinispan/infinispan-benchmarks/blob/main/cachestores/src/main/java/org/infinispan/jmhbenchmarks/InfinispanHolder.java that should work.
Hi guys so I'm new to vue and I know the basis even built my own app but I always asked my self when should I use mounted and created. I'm always concerned about optimization and right now I put all my code in created (fetching from API etc) but I was wondering when should I put for example axios calls inside mounted or created for optimization purposes etc.
You should use created unless you need access to the element this.$el (or any other element ref) then use mounted instead.
There isn't really any optimization improvement using one over the other, as long as you choose a convention and stick to it.
I found some function 'renice' that changes the nice value of process.
But I want to know how to change priority in kernel code.
Is it okay that just changing the priority value in sched_entity of process?
If you want to change the niceness of the process programmatically, I would advise against setting these values in the kernel struct directly. Instead, you can utilize several POSIX functions such as setpriority or pthread_setschedparam.
The default scheduler policy on Linux is SCHED_OTHER, so you're, by default, achieving the same thing using these two functions, as SCHED_OTHER just uses niceness level to schedule.
If you have access to the task_struct, in order to achieve this directly, you just need to set static_prio in task_struct.
Using the dojo toolkit, what is the proper way of locally testing code that will be executed as cross-domain, without making the actual build?
As it appears, there are three possible options (each, with their own drawbacks):
Using local (non xd) XMLHttpRequest dojo.require
This option does not really test the xd behavior, since it dojo.require[s] the js synchronously via XHR.
djConfig.debugAtAllCosts = true;
Although this option does load the required code asynchronously (via the 'script' tag), it also pulls the code in via XHR, parses the dojo.require[s] inside that, and pulls them in. This (using the loader_debug), again, is not what the loader_xd is doing. More info on this topic in a different question.
Creating a cross-domain build
This approach requires a build, which is not possible in the environment which I'm running the code in (We're using our own on-the-fly build process, which includes only the js that is necessary for a particular page. This process is not suitable for development).
Thus, my question: is there a way to use the loader_xd, which does not require an xd build (which adds the xd prefix / suffix to every file)?
The 2nd way (using the debugAtAllCosts) also makes me question the motivation for pre-parsing the dojo.require[s]. If the loader_xd will not (or rather can not) pre-parse, why is the method that was created for testing/debugging doing so?
peller has described the situation. If you wanted to just generate .xd.js file for your modules, you could look at util/buildscripts/jslib/buildUtilXd.js and its buildUtilXd.xdgen() function.
It would take a bit of work to make your own script, but you could look at util/buildscripts/build.js for pointers.
I am hoping in the future for Dojo (maybe Dojo 2.x timeframe) we can switch to a loader that just uses script tags with a module format that has a function wrapper around the module, something that is coded by the developer. This would allow the same module format to work in the local and xd cases.
I don't think there's any way to do XD loading without building and deploying it. Your analysis of the various options seems about right.
debugAtAllCosts is there specifically to solve a debugging problem, where most browsers, until recently, could not do anything intelligent with code brought in through eval. Still today, Firefox will report exception in the console as appearing at the eval site (bootstrap.js) with a line number offset from the eval, rather than from the actual eval buffer, and normally that eval buffer is anonymous. Firebug was the first debugger to jump through some hoops to enhance the debugging experience and permitted special metadata that Dojo's loader injects between the XHR and the eval to determine a filepath to the source. Webkit/Safari have recently implemented this also. I believe debugAtAllCosts pre-dates the XD loader.