I am adding products to wish-list and storing that products in local Storage in
a component & in our root components I am showing the total count of wish-list
products. The problem is that when I add a new product in the wish-list it
will be stored in local storage and it will not update the total counts of
wish-list products in my root component of ionic application.
Angular Service
What you need to do is generate a service which stores the Favorites data and then point that at it. Josh has a good introduction to this:
When to Use Providers / Services / Injectables in Ionic | joshmorony - Learn Ionic & Build Mobile Apps with Web Tech
Basically the high-level overview is that you generate a service which can be injected into each component / page that you want to use it with and then it can provide services to them.
For example you might make a login service so you can find out if the user is logged in from anywhere in the app, or you might want an analytics service, or it could be something more specific like maybe writing a weight conversion class that you can apply to many pages.
Custom Events
Another alternative to this is to have the favourites button emit a custom event which the menu item can listen for to update its own stored favourites value.
This is introduced well in this article:
Using Events in Ionic to Pass Data & Messages Between Pages
The high-level overview is that you publish an event from one page:
this.events1.publish('my-message', '👋 Hello from page1!');
And then you handle that event on another page/component:
this.events2.subscribe('my-message', (data) =>{
console.log(data); // 👋 Hello from page1!
});
Related
So i have a customer that wants to keep his inventory in sync with the supplier (who has a stock API) in magento I wrote a plugin that on page load updated the inventory and then re-rendered the page showing the updated value.
I've seen that shopify has an API, but I couldn't see if what I wanted to do was do-able.
Has anyone got any thoughts?
I could hit the API every 15mins and updated all the products, but this seems like an overkill
You cannot update Shopify inventory in real-time without using an App. Install your custom App in your client store. That App can then securely call the supplier API and get values for inventory. Using your API permissions in the Shopify you can then update Shopify
As David said you need an app. It can be a custom app, that is an app that you don't think to put on the market place and that is only available on a particular store.
In particular, I don't think you need an embedded app, you just need to have the access token and make your REST calls.
You will need to create one webhook on Shopify and one webhook on Magento, to syncrhonize the two stocks.
I don't have any knowledege of Magento but on Shopify the webhook that I think you should use is inventory_levels/update that is triggered whenever the stock changes, and that also depends on the location of your products. The same you should do on Magento.
This is a python script that is doing the update when receiving the webhook
def sync_inventory():
inventory_request = app.current_request.json_body
inventory_id = inventory_request["inventory_item_id"]
location_id = inventory_request["location_id"]
if location_id not in WAREHOUSE_IDS or inventory_id not in INVENTORY_IDS:
# Discarded inventory event
return {}
return sync_inventory_data(inventory_id) # do your magento call here
I have an app and its going to have these features in it :
SCREENS :
Home { Show recent posts from all categories (API provides 30 posts per page)}
Categories {Show all Categories List }
By-Category {Show recent posts by category (API provides 30 posts per page)}
Post {Show Post Details with Comments }
User-Profile {Show User Profile with their recent posts (API provides 30 posts per page)}
Profile-Setting {Show updatable Fields and Update Button}
Now, Where i am confused :
Should I fill the whole store with API in the starting or should I
make API calls for each screen when they are opened ?
And for updating, like If user likes post then should I show a
spinner or something till API completes OR should I update the local
store value instantly and then call the API ?
There could be many approaches to solve this. mine is:
1) I would create a model/manager to handle the API requests that also have access to the same store. so for example when the screen did mount use Home.Manager.getNextPage(); and it will know already to handle the api request and also know how to handle the paging.
So all the calcs will be in the manager. and when it get the data it will update the store with it.
2) When I built an app that contained likes I have used local data as well. My approach was to set time out of 10 seconds from last like so in case the user liked more than one post I could send a bulk. so the server won't need to handle multiple tcp connection but one with multiple likes data.
The point was first store it locally(for incase the user kill the app before we update the server) and then wait for 10 s' if got new like add it to the data array and wait for another 10 s' if not just send the data to the server. do not clean this local data until server return that it saved on your db
This way you can display animation first without letting the user to wait for a feedback from the server..
The best practice is to make small API calls for each component.
You should load each screen with a loading, then call the API in
componentDidMount after receiving the response shows the data.
enter code here
For this kind of action, first, make the API call, make the like button disable, update the store after successful API call.
Disable the button because of some user double-tap. This kink of APIs is usually fast, so loading does not have a good UX. The loading will be removed before full animation. Always update store data on the response, not the request because you need to revert the store changes if the API calls failed.
I am doing some work for a client who uses BigCommerce Stencil Theme and I am pretty new to BC. Until now most of my work with them has been basic theme formatting and styling.
They are asking if I can add checkboxes next to items in cart to indicate an alternative delivery system, and then add a field to address for a hotel room. It seems like built into BC checkout customization you can add fields to addresses so that doesn't seem like an issue, but I'm not so sure about the checkboxes. I would imagine I would need access to the underlying PHP to make this happen which doesn't seem possible. Is this accurate? If not, how might I go about doing this?
I see that I can add the checkboxes themselves to the template files, but as far as sending any data with the checkout I don't know how I'd go about doing this.
For the hotel room address field, you are correct that the simplest solution would be to use the built-in custom address field feature.
For the checkbox/alternate delivery system, we're close to releasing a new Checkout JS SDK that will give you the ability to create a completely custom checkout experience. The SDK is basically a Javascript wrapper for our Storefront Checkout API and it includes operations for checkout actions (like creating a new shipping consignment for an alternate delivery method).
The Checkout SDK doesn't give you access to the underlying PHP; instead, it allows you to create your own frontend using React or whatever framework you prefer. The logic for custom checkout steps would exist in your frontend, and you would send your data to the checkout via the BC Checkout API.
https://stencil.bigcommerce.com/docs/customizing-checkout
I'm using Vuex & Vuejs (flux architect) for a CRM single page application.
In contact page i'm showing a list of tasks related to current contact and at sidebar i have a list of task for current logged in user.
These collection of tasks are kept in separate stores. I don't know which is best solution:
After update post request search in both list and update task object if it's present and mutate state.
After update post request use an global event bus and each store should listen and update task object if needed.
It really depends of your requirements, but one thing I can tell is that using two separated stores + bus is defeating the whole purpose of Redux.
If the tasks in your application share the same scope and can be assigned to you or other users that you may be visiting/managing, you can have all the tasks from your scope (your team, for example) and display it on different places using different getters with Array.filter functions.
If the number of tasks is too big to have it all loaded, I'd approach it doing one single tasks list in the store, being populated from a single url.
ie:
- Give me all the tasks I have + the tasks of current user I'm managing
- Give me all the tasks I have + the tasks that matches this search
Although this can get messy if the requirements are more complicated and can get confusing. But try to structure your application with one single store if possible and avoid bus, as it is only recommended for small size applications.
Let's say I have this blog app. There are posts, pages, menu, and user login.
One way to load the entire application state is to have one api call which will include posts, total number of pages for pagination, menu items and current user state.
The second way would be to have multiple API called, one for each component. So one call for posts and pages, one for menu and one for current user.
Which would be best strategy given the fact react is built around components?
I'll add my 2 cents as answer but still wanting to close as primarily opinion based.
The way I structure my React apps is to have a top level components called Screens or URLs, ie., /list-users should map against the ListUsersScreen component.
In said screen I declare a static method called fetchData, this method returns an object which values are Promises.
{
users: fetchUsersAction(),
someOtherApiData: fetchSomeOtherAPIData()
}
This lends well to both pure client apps and universal apps, as well.
On your server side you'd have to wait until all Promises resolves until you can render something.
Furthermore you can easily cache the values in your application state object and decide if you want to fetch new data or render stale data, also it saves on bandwidth for your user since the user might or might not decide to continue browsing your site.