Im fairly new to redux, my question is. Do i need to use middleWare if i am using Redux-thunk. I need to make an API call and i want to know what i need in order to make that call using redux. I know how to do it without redux, but now i am building my E-commerce site and i need to use redux, but i am not very familiar with using thunk to fetch data. There are plenty of tutorials out there but non of them really helped or they are outdated. If someone came across a video feel free to post the link. Thank you in advance!
Best course of action would be to go through the official redux essentials tutorial which teaches modern redux and also has a whole chapter on data fetching (but read it from the beginning!)
Related
When I searched for Redux most of the time I get the answer
Redux is a predictable state container for JavaScript and comes as an
external library which can be used together with front-end frameworks
like React, Angular, Ember.js, Backbone, etc.
I did not get the definition actually. What does it mean by **predictable state container **?
And as a new tool, it should solve some problems with web development. So, what redux does and how it facilitates us?
I think when someone says that Redux is a predictable state container it means that redux has a very strict way how to change the data, sometimes called unidirectional data flow.
I mostly used it in React application, so I can tell which problem it solves in this case. While your application is small, you probably will not see the reason to use Redux, but when it grows, when you have lots of components which use the same data and have to communicate with each other, it becomes really painful to store all state somewhere in the root components and pass it through all the children. There may be performance issues as well, all components between a root one a chield which needs some part of your state will be re-rendered.
So using Redux easily connect your components and select those parts of the state which they need. Also, communication between components becomes much easier, instead of passing callbacks to props, your components just listed to state and represent it, any time you need to change a state just send an action.
Regarding predictable state management, Redux is some kind of event sourcing, instead of changing a state directly, so send actions (events) which describe how to modify the state and reducer applies these changes.
There are way more things to say about Redux, at least middlewares, if you are familiar with Rx, you can try to use redux-observable which are really powerful, you can listen to some actions or a state changes to combine it with others. I recommend you to take a look at redux documentation and some article like this, I believe you will find an answer to your question.
I'm learning ReasonReact and I would like to fetch data from a API, that I'm going to use on my component. However, on the official website about Reason or ReasonReact there's nothing about this, neither I found something searching on Google. How can I do it?
You can use the existing bindings to HTTP client libraries, e.g.:
https://redex.github.io/package/bs-fetch
https://redex.github.io/package/bs-axios
The former works in browser only, the latter works in both browser and Node.
In general, if you're looking for a way to do something, Redex is a great place to look.
Every tutorial/example i can find for meteor shows a single view application. I would like to build something a little more complex. I'm unclear how to approach multiple views...preferably in a way that's somewhat scalable?
The iron-router package lets you access different views (layouts) by nice, REST-ful human-friendly clean URLs. It supports parameters in the URL, "loading" templates, waiting for subscriptions to finish loading, before and after hooks etc.
At this point you can only create Single Page applications with Meteor. Note that Single Page, doesn't mean you can't have several views - use iron-router for that.
But by design, Meteor serves a big fat unique JavaScript/HTML/CSS application down to the browser, though there's a feature request to allow incremental loading. It is then up to the application (or more precisely, the JavaScript framework), to dynamically render its views in order to display different "pages".
I was wondering the same thing and it took me way too much time getting something started. I finally got a paged app working solidly by using Backbone views and routes, so I created a simple boilerplate project to make setting up an app like this easier in the future.
Live demo here: backbone-boilerplate.meteor.com
Source code here: github.com/justinmc/meteor-backbone-boilerplate
Have you looked at madewith.meteor.com?
A bunch of apps there have multiple views using Backbone also Jonathan Kingston who created britto has started simple meteor framework called Stellar
At this stage of the game not sure if there really are best practices. But these two seem to be the current flow.
You can also make a tabbed interface for multiple views. There is a package project "Smart package for generating a tabbed interface with pushState" github project here: https://github.com/possibilities/meteor-tabs
The best solution right now is using a routing package (router is basic but works). The workflow is something like this:
declare routes; return a template name for each route
place the reactive helper provided by the package in your body tag
the reactive helper will return the template associated to that route
you create a template for each route and optionally set custom publish functions
Router will give you browser history (client side).
Note that at this time there are some limitation on the way Meteor handles html/js. They are load all at the same time. The bright side is that once the app is loaded, page transitions will be instant.
I'm new to Drupal, but I want to create an add-on. The add-on requires some sort of multi-page form with advanced jQuery (I already looked at the jQuery module).
The add-on requires details of the current logged in user and will also communicate with an external database.
I've been looking at tutorials concerning Module creation etc. But they mostly cover creation of simple forms, where as what I want to create is more of a plugin.
Multi page forms are a total drag. Pro Drupal Development, has a very good section on this topic, and I highly recommend that book if you are doing any Drupal development.
Online I found the following article pretty useful too (though I ultimately went with my own system).
http://www.nicklewis.org/using-chaos-tools-form-wizard-build-multistep-forms-drupal-6
There's a decent example here:
http://thedrupalblog.com/creating-multipage-form-using-forms-api
To make the most out of this, you're going to want to get pretty friendly with the Form API:
http://drupal.org/node/204270
Sadly Drupal.org seems to be missing a Drupal 6.x explanation (though plenty exist for 5.x and 4.7 oddly enough).
Multi step forms are complex by nature, but there are some methods to make it easier. I recommend that you have a look at the multistep form tools offered by the Ctools module. This blog post by Nick Lewis explains how you can use it.
I think you should think twice before going with javascript/jQuery to create your forms. Javascript is a great way to improve the user interface, but it can be easily manipulated because it's client side technology. You shouldn't rely on javascript alone for things like input validation, temporary storage of form values and controlling the flow between different steps of the form.
I feel odd saying this, but I don't think you want to use the Drupal Forms API.
The Forms API provides a lot of security features (unique token, rebuilds form after submit to compare to ensure correct form is processed, etc.) and allows other modules to modify your forms, but I think a lot of those features will get in the way of your jEditable form. Multi-page forms are not that challenging using the Forms API, but jEditable elements will be.
Your module could simply add a menu item with a page callback function that puts together your jEditable form for you. That is about as close to the world of a 'normal PHP' script as Drupal will let you get.
Hi I have to do a small CMS application in MS ASP.NET using WebForms.
I do everything on my own: front-end and back-end and Data Base schema.
Now that I want to develop the site, I wonder if I should start from front-end first, or back-end.
Considering this is a small project, could you guys give me a list of steps I do better following to help to determinate what is the best order for developing my application?
Thanks once again for your time.
You'll develop all tiers as you go most of the time
For some page you may first create database schema and fill it up with some dummy data and than work your way up.
For others you may start with a page itself and then write functionality that's needed to get it working. Especially when this page hasn't been envisioned enough. This is not bad nor good. It's just the way development tends to be.
Some considerations
Follow agile development
Write down some requirements in a form of user stories (and keep track of them), that don't give any info about page, data etc. Just something like As a user I would like to have primary navigation on my page. This kind of a story will permit later changes to code/pages without the story becoming invalid.
Don't haste into something fully functional at first. Don't over-engineer your code. Because you'll end up doing changes later = follow YAGNI. For instance don't fully design your DB at first. Do just as much as you need per story being developed. But do think of future things that you'll have to integrate into existing codebase.
Refactor existing code right away when you see something should be changed.
If you have someone to test your code, let them do it. Don't develop next stories before existing bugs have been fully resolved. You'll be grateful for this later.
If your code is semi-complex I suggest you write unit tests, so future code changes won't break existing functionality.
Most of all: learn as you go and change existing code while doing so. Since you're learning these technologies I suggest you stick to simplicity at first. You'll add more complex things when needed. Some of them won't get done at all. So in the end youl realise YIDNI (yep, I didn't need it).
I usually write out what my requirements are first, if I need to use a database, I create that first, always. After my database I start working on front end that connects and uses my already created database.
I worry about the front-end last, can you can always change that pretty easily
I would say that in many systems, the back-end is there to support what is needed for the front-end to work. If you don't know what the front-end needs, there is little chance of successfully designing the back-end. So I'd start off with putting at least a rough front-end in place first (if even just a paper prototype).
I tend to approach all of my projects with a back-to-front approach for one simple reason - testability. Writing solid tests against a back-end early will will make it easier to work on the other tiers progressively. It also, as "bonus" helps to keep business logic out of places it does not belong.
I find it easier to develop the logic and back-end first, so that I get that right, then apply the interface to it. This way you avoid writing functionality based on what you think you need from the front end.
It is important to get a good scope of what you want to do/tackle, and try to implement that in the back-end first. Then wrap it in a nice interface!