UserActions logic is moved to #spartacus/user - spartacus-storefront

Based on this upgrade suggestion I’m trying to import UserActions/UserDetailsAction from #spartacus/user lib but am getting the error has no exported member.
// TODO:Spartacus - UserActions - Following actions 'ForgotPasswordEmailRequestAction', 'ResetPasswordAction', 'EmailActions', 'UpdatePasswordAction', 'UserDetailsAction' were removed. Logic was moved to '#spartacus/user'
Module ‘“#spartacus/user”’ has no exported member ‘UserActions’.
import { UserActions } from '#spartacus/user';
this.store.dispatch(new UserActions.LoadUserDetails(user));
import { UserActions } from '#spartacus/user';
Tried to import UserActions from the user lib

According to the technical changes documentation, you should use the new recommended approach with commands and queries as mentioned in the link. But you can also try importing from #spartacus/user/account, #spartacus/user/profile or #spartacus/core bearing in mind that your previously used actions may not exist anymore.
In case it helps, a similar question was also asked here.

Based on technical changes in Spartacus 4.0, Some branches of the ngrx state for the User feature were removed and logic has been moved to facades in #spartacus/user library.
In your case, instead of dispatching an action, simply use the get method from UserAccountFacade that is part of #spartacus/user.

Related

BigQueryCheckAsyncOperator in airflow does not exist

I am trying to use async operators for bigquery; however,
from airflow.providers.google.cloud.operators.bigquery import BigQueryCheckAsyncOperator
gives the error:
ImportError: cannot import name 'BigQueryCheckOperatorAsync' from 'airflow.providers.google.cloud.operators.bigquery'
The documentation in https://airflow.apache.org/docs/apache-airflow-providers-google/stable/operators/cloud/bigquery.html mentions that BigQueryCheckAsyncOperator exists.
I am using airflow 2.4.
How to import it?
The operator you are trying to import was never released.
It was added in PR and removed in PR both were part of Google provider 8.4.0 release thus overall the BigQueryCheckAsyncOperator class was never part of the release.
You can use defer mode in the existed class BigQueryCheckOperator by setting the deferrable parameter to True.

ACE editor - allow custom modes and themes in Angular/TypeScript

Introduction:
I've an Angular application where custom SQL statements can be written by using the ACE editor (https://ace.c9.io/). Even though there are modes and themes for SQL, I wanted to create a custom mode and a custom theme for my requirements.
Setup:
I followed this tutorial: https://blog.shhdharmen.me/how-to-setup-ace-editor-in-angular
ng new ace-app (Angular 13.3.2)
npm install ace-builds (ACE-Builds 1.4.14)
component.ts
import * as ace from 'ace-builds';
...
public aceEditor: ace.Ace.Editor;
#ViewChild('editor') private editor!: ElementRef<HTMLElement>;
...
ngAfterViewInit(): void {
// I don't understand why we don't set the "basePath" to our installed package
ace.config.set('basePath', 'https://unpkg.com/ace-builds#1.4.12/src-noconflict');
this.aceEditor = ace.edit(this.editor.nativeElement);
if (this.aceEditor) {
this.aceEditor.setOptions({
mode: 'ace/mode/sql',
theme: 'ace/theme/sqlserver',
});
}
component.html
<div #editor></div>
Result:
The editor is working, but now I need to somehow add a custom mode and theme.
Problems and Questions:
Is it correct to set the basePath to an external URL if I've the package already installed (obsolete due to Edit 1)?
How and where would I add the custom mode.js and theme.js?
How can I direct ace to the custom mode.js and theme.js?
Edit 1:
I managed to get rid of this line of code:
ace.config.set('basePath', 'https://unpkg.com/ace-builds#1.4.12/src-noconflict');
by directly importing the theme and mode with:
import 'ace-builds/src-noconflict/mode-sql';
import 'ace-builds/src-noconflict/theme-sqlserver';
the rest of the code did not have to be changed.
After looking through several projects and issues, I figured out that the best way to implement custom themes and modes for the ACE editor is to copy existing ones from ./node-modules/ace-builds/src-conflict and paste them to ./src/assets/ace.
Example:
Copy an existing mode (and optionally the theme) that represents your required syntax highlighting the most, in my case it was mode-sql.js. I copied the files to ./src/assets/ace and changed the import in my component.ts from:
import 'ace-builds/src-noconflict/mode-sql';
import 'ace-builds/src-noconflict/theme-sqlserver';
To:
import '../../../../assets/ace/mode-sql.js';
import '../../../../assets/ace/theme-sqlserver.js';
Everything else was kept exactly as described in the initial question. From there you can start to change the name of mode and theme, update the rules as well as the styling according to your requirements.

quarkus reactive getting started PUT and DELETE operations

I'm going through the quarkus reactive getting started page and PUT and DELETE method implementations are missing.
Seem like it assumes we already know quarkus and are just reading the guide to switch from non-reactive to reactive. Why they don't provide a full example, I don't know. I mean where would you learn if not by a guide or someone showing you how it's done?
PUT should replace an entry and DELETE should delete one.
PUT /{id} = replace
DELETE /{id} = delete
Instead of Fruit my entity is named Profile.
package de.icod.reso.resources;
import de.icod.reso.entities.Profile;
import io.quarkus.hibernate.reactive.panache.Panache;
import io.quarkus.panache.common.Sort;
import io.smallrye.mutiny.Uni;
import javax.enterprise.context.ApplicationScoped;
import javax.ws.rs.*;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
import java.net.URI;
import java.util.List;
import java.util.UUID;
#Path("/profile")
#ApplicationScoped
#Produces(MediaType.APPLICATION_JSON)
#Consumes(MediaType.APPLICATION_JSON)
public class ProfileResource {
#GET
public Uni<List<Profile>> get() {
return Profile.listAll(Sort.by("name"));
}
#GET
#Path("/{id}")
public Uni<Profile> getSingle(UUID id) {
return Profile.findById(id);
}
#POST
public Uni<Response> create(Profile profile) {
return Panache.<Profile>withTransaction(profile::persist)
.onItem().transform(inserted -> Response.created(URI.create("/profile" + inserted.id)).build());
}
#PUT
#Path("/{id}")
public Uni<Response> replace(UUID id, Profile profile) {
// error: incompatible types: incompatible parameter types in method reference
return Panache.<Profile>withTransaction(profile::update)
.onItem().transform(updated -> Response.ok(URI.create("/profile" + updated.id)).build());
}
#DELETE
#Path("/{id}")
public Uni<Response> delete(UUID id) {
// delete entity by id
}
}
Can you fill the 2 missing functions?
I'm aware there is Quarkus Getting Started (w/ Reactive): PostGres/Docker CRUD Application -- Missing POST, PUT, and DELETE REST URLs
but the contents are different from what's written in the getting started page.
Generally speaking, the Getting Started and the quickstarts might be slightly different. The reason is that the purpose of the Getting Started is to help a new user to set up a small working project quickly and the quickstart is a place to showcase different functionalities of the extensions involved.
We try to make sure that the documentation is always up to date but nothing beats a working example like the quickstart.
In this case I don't understand your complains.
An example of PUT and DELETE is available in the Hibernate Reactive with panache quickstart:
#PUT
#Path("{id}")
public Uni<Response> update(Long id, Fruit fruit) {
return Panache
.withTransaction(() -> Fruit.<Fruit> findById(id)
.onItem().ifNotNull().invoke(entity -> entity.name = fruit.name)
)
.onItem().ifNotNull().transform(entity -> Response.ok(entity).build())
.onItem().ifNull().continueWith(Response.ok().status(NOT_FOUND)::build);
}
#DELETE
#Path("{id}")
public Uni<Response> delete(Long id) {
return Panache.withTransaction(() -> Fruit.deleteById(id))
.map(deleted -> deleted
? Response.ok().status(NO_CONTENT).build()
: Response.ok().status(NOT_FOUND).build());
}
For your use case you need to use Profile instead of Fruit, and UUID instead of Long for the id. I don't think you need anything else to make it work.
// error: incompatible types: incompatible parameter types in method reference
The error message is telling you the cause of the problem: the syntax Panache.withTransaction(profile::update) is not correct.
This won't work because profile.update(...) expects additional parameters that you are not passing when using method reference with withTransaction.
On the other hand, one can use Panache.withTransaction(profile::persist) because profile.persist() is a method that doesn't require parameters.
This is how method reference works in Java.
That said, the documentation is never done and it will get better over time based on the feedback we receive.
Also, StackOverflow might not be the best place for this type of questions.
I would have probably asked this on the users stream on Zulip first. It's even faster to receive an answer if you push an example of the code that's giving you trouble somewhere, so that we can run it and give you precise help about what's wrong with it.
I'm aware there is Quarkus Getting Started (w/ Reactive): PostGres/Docker CRUD Application -- Missing POST, PUT, and DELETE REST URLs
The example in this question is 2 years old and things have changed since then. In fact, the same quickstart and tutorial referenced in that question now match the code I've used.
You can find the information you are asking for at https://quarkus.io/guides/hibernate-orm-panache#writing-a-jax-rs-resource.
You can also compare reactive vs. non-reactive versions of the same application by looking at the Hibernate Reactive Panache Quickstart and the Hibernate ORM Panache Quickstart

Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle

I am receiving this warning message in my chrome console for my react-native project. Do you have any idea why I am getting this?
This is the complete message:
Require cycle: node_modules/react-native-radio-buttons/lib/index.js ->
node_modules/react-native-radio-buttons/lib/segmented-controls.js ->
node_modules/react-native-radio-buttons/lib/index.js
Require cycles are allowed, but can result in uninitialized values.
Consider refactoring to remove the need for a cycle.
I appreciate any suggestions.
Thanks
TL;DR: You import module A into module B and module B into module A resulting in a cycle A → B → A → B → A ..., which can result in errors. Resolve that by restructuring your modules, so that the cycle breaks.
Detailed Answer
In javascript if you import different modules into other modules all this importing generates a dependency tree:
root_module
┌───────────┴───────────┐
sub_module_A sub_module_B
┌────────┴────────┐
sub_module_C sub_module_D
When you run your code, all modules will be evaluated from bottom to top or from leaves to the trunk, so that for example if you import modules C and D into module B all exports of C and D are already evaluated and not undefined anymore. If module B would be evaluated before C and D, module B would be not working, because all exports from C and D would be undefined, since they have not been evaluated yet.
Still, it can be possible to form cycles in your dependency tree (this is what you got a warning for):
root_module
┌───────────┴───────────┐
sub_module_A sub_module_B
↑ ↓
sub_module_C
Problem: Let's say the evaluation starts now with module C. Since it imports something from module B and it has not been evaluated yet, module C is not working correctly. All imported stuff from B is undefined. This actually is not that bad, since in the end module C is evaluated once again when everything else has been evaluated, so that also C is working. The same goes if evaluation starts with module B.
BUT: If your code relies on a working module C from the very beginning, this will result in very hard to find errors. Therefore you get this error.
How to solve: In your case the warning also gives a detailed explanation, where the cycle emerges. You import native-radio-buttons/lib/segmented-controls.js in node_modules/react-native-radio-buttons/lib/index.js and node_modules/react-native-radio-buttons/lib/index.js in native-radio-buttons/lib/segmented-controls.js. It seems like the cycle is placed inside some of your node modules. In this case there is unfortunately no way you could solve that by yourself.
If the cycle is in your own code, you have to extract some exports into a third module / file, from which you import the code into both modules previously forming the cycle.
You are probably importing something from "file A" into "file B", then importing something again from "file B" into "file A" .
Examine all the imports from both the files and see if there's any such cycle.
To prevent from having to write multiple lines of
import SomeComponent from "../components"
import AnotherComponent from "../components"
import AndAnotherComponent from "../components"
import AndOneMoreComponent from "../components"
I created a comp.js file where I could import the components as they are created and export them as modules.
All components are then able to be reached from one place.
So you can then have something like this in some place...
import { SomeComponent, AnotherComponent, AndAnotherComponent, AndOneMoreComponent} from './comp'
Now what happens in the renderer for example when SomeComponent is rendered....
import * as React from "react";
import { AnotherComponent} from '../comps';
import { View, Text } from "react-native";
function SomeComponent() {
return (
<>
<AnotherComponent />
<View><Text>EXAMPLE OF SOMECOMPONENT</Text></View>
</>
)
}
export default SomeComponent;
In the example, SomeComponent could be called in the main App, and when it renders it also asks for a component from the comp.js
This is what triggers the Require cycle warning because a module that was imported from one place, is then rendering and asking to import another module from the same place it was rendered from.
What are your thoughts on this, should I revert back to using single import statements or do you think there is a danger in using the module export as it is currently setup?
I my case, I have sold the same problem in react-native navgiation.
What I did ?
Already I was using react-navigation like below
export const containerRef = createRef();
function App(){
return (
<NavigationContainer ref={containerRef}>
....
<NavigationContainer>
);
}
and then I was consuming it like:
import {containerRef} from 'filename';
onPress = ()=> containerRef.current.navigate('Chat');
But I updated like below and warning has gone.
function App(){
return (
<NavigationContainer> // removed ref
....
<NavigationContainer>
);
}
and then I was consuming it like:
import { useNavigation } from '#react-navigation/native';
onPress = ()=> useNavigation.navigate('Chat');
This occurs if your code contains cyclic dependencies. If these dependencies exist within your own libraries, you can easily fix them. But if this is happening in 3rd party libraries, you can't do much except waiting for the developers to fix these.
Another reason might be this: Some imports cause this warning if they're done through the require keyword. Replace these with import statements and you might be good to go. For example,
const abc = require("example"); // Don't use this syntax
import abc from "example" // Use this syntax instead
NOTE: This might vary from project to project. For a detailed understanding of require vs import, refer to this link.
In my case the warning was like this;
Require cycle: src\views\TeamVerification.js -> src\components\TeamVerificationListItem.js ->
src\views\TeamVerification.js Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle.
As it indicates, TeamVerification was importing TeamVerificationListItem and TeamVerificationListItem was also importing TeamVerification. It was an unused import but after I remove it the warning gone.
As others have already mentioned, for your own packages
Move things required within two modules by each other into a third module
Avoid imports from barrel-files (index.ts/js) or aliases (#mycompany/my-module) if you are within the same "my-module"
What others have not mentioned (and which seems to be the problem for OP), for packages not within your responsibility (eg node_modules from NPM), the only thing you can do is
Disable the warning. It will still show up in metro console, but no more yellow warning snackbar: import { LogBox } from 'react-native'; LogBox.ignoreLogs(['Require cycle: node_modules/']); You can place the code in App.tsx, for example.
Modify the package contents of the node_modules itself and patch the package contents after every npm install via patch-package => I think this is an overkill if the circular imports don't produce actual errors
You should use the Relation wrapper type in relation properties in ES Modules projects to avoid circular dependency issues, just click here: https://typeorm.io/#relations-in-esm-projects
In my case, i had the same warning after the installation of a 'package'
and in their documentation, it was import SomeFunc from 'package'
and instantly the warning showed up
Require cycles are allowed but can result in uninitialized values. Consider refactoring to remove the need for a cycle.
but as soon as I destructure the SomeFunc there was no more warning
import {SomeFunc} from 'package'
please look at the destructuring
I used react-native-maps in my project and I got the same error.
Just upgraded from 0.27.1 -> 0.28.0.
I can confirm that this issue is fixed.
Thank you
if use NavigationContainer in #react-navigation/native
import {createRef} from 'react';
<NavigationContainer ref={createRef()}>
Please check whether you have imported same details within that file.
(i.e)
your file being as a actions/meals.js and you have added the line in the same file like
import { Something } from './actions/meals.js'

Accessing vuex modules data from within a plugin

I am moving some data from the vuex store into its own module. Most of it works great, but I'm running into an issue that I can't seem to fix.
I have a plugin that I add, and that plugin also needs access to the store.
So at the top of that plugin, we import the store:
import store from '../store/store';
great - further down that plugin, I'm accessing the data of the store in a method that I expose on the service:
hasPermission(permission) {
return (store.state.authorization.permissions.indexOf(permission) >= 0);
}
Please note authorization is now a seperate module, and is no longer part of the root state object.
now the funny thing is that the above will return an error telling me indexOf is not a function.
When I add the following, however:
hasPermission(permission) {
console.log('Validating permission ' + permission);
console.log(store.state);
return (store.state.authorization.permissions.indexOf(permission) >= 0);
}
I notice that (1) the output to console is what I expect it to be, and (2), I'm not getting the error, and my menu structure dynamically builds as expected...
so I'm a bit confused to say the least...
authorization.permissions is updated each time a user authenticates, logs out, or chooses another account to work on; in these cases we fetch updated permissions from the server and commit it to the store, so we can build our menu structure based on up-to-date permissions. Works pretty good, but I'm not sure I understand why this fails to be honest.
The plugin is created as follows in the install:
Vue.prototype.$security = new Vue(
...
methods: {
hasPermission: function(permission) {
...
}
}
...
);