I'm following an Angular2 course having a background of Sencha ExtJS framework.
My question is pretty easy : with AngularJS how do you store and interact with big data structures? In all the course when a Service was retrieving data was always small and was stored in an array.
Why did I mention ExtJS? Because it offers classes called Store to, as the name says, store data and query it, with possibility of filtering,sorting,mapping and so on.
Let's make an example :
I have the list of the airports in the world and I want to offer it in a select. Of course i will setup the service injected to the select that offers the entire list. But then:
-I want to filter it as the user go on typing
-The array containing the data is an array of objects with other properties after the name like the country or the id
Which is the approach to follow?
As per my comments, here's my answer.
In Angular 2 we have smart components, which hosts logic and data, and dumb components which are pure views, with no logic and preferably stateless.
Ideally, you could retrieve your data from the API and deliver it to your smart components either returning the whole data or exposing a stream with RxJS.
An example using RxJS would be:
A service calling the APIs and returning an Observable with the data
A smart component consuming the service's data, in the form of a Subscription
One or more dumb component in showing the data which is pushed down by the smart component (acting as a container)
At this point, your data manipulation could reside either in the service or in the smart component (it depends on what you need to transform and how).
To manipulate the data, I suggest you use RxJS which offers the possibility to chain streams and filter, aggregate, map, ... methods. It is asynchronous.
If you can go for something less complex but blocking (it depends on your requirements), I'd suggest you use Lodash, which brings methods for collections to chain, map, filter, and aggregate data.
Related
Summary
I am writing a React-Redux application, and would like to create a service that can be accessed across multiple components, with the following characteristics:
Singleton (just gets instantiated once across the entire
application)
Injectable (can be injected into, and used by, multiple components across the application)
Redux Connected (can access the entire Redux state tree & received updates to state changes)
Code Example
The type of solution I have in mind, would allow me to inject a service int a React Component, and use in the following way:
{ featureAvailabilityService.isAvailable('myFeature') && (<MyFeature />) }
Ideas
I have read about High Order Components, Hooks, and the Context API. There are also some interesting libraries, such as Unstated, and Redux-Logic. I feel like the best answer probably lies somewhere between these, but could use some guidance to put me on the right track.
Use Case
In this instance, I would like to create a reusable service, which has methods to determine the availability of certain features. This involves relatively complex logic based on System, Tenant, and User configuration and state. It also requires the service to have access to state from several different parts of the application. It will also be reused broadly across the application.
Why Yet Another React Service Question?
I realize there are already a lot of similar questions to this, usually from people with an Angular background, looking for the React equivalent to an Angular Service. However, I have not yet found an answer that provides for the above three criteria... or at least not one that I understood.
Thanks for any input.
I have a web service built with Spring, my view is built with React and I use Redux for state management.
Let's say my API has an endpoint /api/products and I've implemenented search functionality, which pulls all the products from the enpoint, stores them in Redux store and displays them. Now I want to implement sorting functionality and I have two ideas for achieving it:
Modify my api endpoint /api/products to take parameters. For example /api/products?sortBy=price (less logic in UI, more network requests)
Use the products that I have stored in the store. (less network requests, more logic in UI)
Which one of these, if any, would be considered as the best practice?
It would depend on
What is the acceptable latency? How often do you need to call this list? Almost every second, like in an autocomplete field? Say, a few times a minute, for a report which is sorted by different parameters by the user? Or something like a rarely used settings page?
How much data do you have? Is it a few million? or a few dozen? If it is too many, better to filter in the backend and send only the required rows.
How big is each row? If each row is big with many fields, your payload will increase.
Are you having to make a tradeoff between initial load time (to load all the data from the backend once) vs responsiveness (when the user is interacting with the data)?
I hope this will give you the general idea on how to decide. Maybe able to discuss more if you have details of your specific situation.
You have to use backend. If you have like 3000 records, you need to use pagination. You shouldn't sort all pages on frontend, because it would be too much data. You need to use backend to sort and send only data you want to display on specific page.
Please dont use backend functionality in your Frontend.
Spring Boot is an great framework and offers you Sort and Pageing functionalities.
Example:
public interface UserRepository extends CrudRepository<User, Long> {
Page<User> findAll(Pageable pageable);
List<User> findByLastname(String lastname, Sort sort);
}
Please look into the Documentation -> Spring Data Jpa
I'm making an Angular2 SPA with a webAPI REST service that exposes an EntityFramework model.
The quickest way to get going is to load up a big object graph in a single controller action and pass out a big blob of JSON to the client, which can then split it up as it walks the object graph.
Is it considered better practice to build API actions for each object in the object graph and have the JS client pull the graph piecemeal as required?
The piecemeal approach requires many more controllers and actions and, correspondingly, angular services, i.e., more work! Do I need to just grasp the nettle and get on with it?
Actually it depends whether your are using Entity Framework in connected scenarios or in disconnected scenarios. Regarding your case, you are using Entity framework in disconnected scenarios, which mean that DBContext doesn't attach to object graph all the time, because you get the data from database, send it to the client and then close the context. For me, I would recommend to use divide your controllers and actions for each POCO or DTO because this will help you to maintain and attach each object individually rather than maintain the whole object graph at once. The problem will start to appear when you start editing or manipulating your entities because in disconnected scenarios you never know which object has been edited or deleted or added in a big object graph. However, you should maintain and manipulate each change in client side directly to the sever to reflect that update.
I don't know if this answers your question, but if you need any further explanation or code sample. please let me know.
I think you have to make one backend action for one angular2 page-level component. User shouldn't wait for extra data loads, only data that needed on this page.
Basically I'm writing an app and am using Sails, MongoDB and Node JS for the back end. I'll use Sail's API features and was wondering what would be the best way to make the app realtime.
For instance I could use AJAX to call the API and manipulate the DOM using jQuery and update the DB through $.post then let the model update the db in the backend, however I'm finding this approach quite cumbersome. Not to mention I can see the code could become quite difficult to maintain after a while.
I've been doing some research and - if I understood correctly - it seems I could use either Backbone, Angular or Knockout to manipulate the data/DOM on the front end, however I'm not sure what would be the best approach in my case nor whether any of these would indeed suit my needs:
Being able to get the data dynamically
Update the data and the DOM dynamically as the user interact with the page
Post the updated data dynamically with none or as minimal data transformation on the back end as possible
All the above asynchronously
As I don't want this to become a heated debate on which library is best, so I would like to know only whether any of the aforementioned libraries can do what I need and which is the leanest/simplest/has the lighter learning curve.
I did similar research a while ago and when found AngularJS, just stopped looking any further.
Right to your questions:
Being able to get the data dynamically
It is pure pleasure to do it in Angular. For the very basic functionality you have got $http service which allows you to send http request and register a callback when the data arrives.
For more complicated things there are modules ngResource and Restangular (external).
Update the data and the DOM dynamically as the user interact with the page
For manipulating DOM, Angular introduced concept of directive. It is basically future of the web (Shodow DOM and Web Components) right now. At this time point, there is nothing more elegant out there.
Post the updated data dynamically with none or as minimal data transformation on the back end as possible
Yes. JSON.
All the above asynchronously.
Yes, of course.
SailsJS provides interchangeability of HTTP or socket.io connections. In your case I think sockets would be a better fit than AJAX.
I'm fairly new to Django and web-app development, so perhaps my question is not very well thought out.
For a new website I'm working on, I'd like to perform a set of database queries for every incoming request. I'm wondering what the best way to structure this in code would be.
To be more specific, I'd like to display a greeting (such as "Hi John,") and the status of the user's shopping cart in the header section whenever applicable. I considered creating a get_header_details helper function and calling it from every view method, but there has to be a better way to do this. Thoughts?
Also, even though I'd like to display the greeting and shopping cart status on every page, maybe I don't need to query for it on every page request. Is there a good way to do this? This is a learning project, so I'm ok with adding things to my technology stack.
For the shopping chart, middleware and a context processor coupled with sessions and preferably caching (e.g. Memcached) is the way to go.
Middleware allows you to do arbitrary actions before or after every view. A context processor allows you to insert variables into every template. The most common way to implement a shopping chart is the use of sessions, as you normally don't want to save the state of the shopping chart indefinitely by default (you can of course provide this option as a convenience feature).
As for the greeting message, use caching to prevent an extra (probably unneeded) query on every request.
Django has good caching support. Template fragment caching might be useful in your instance.