About the conference: ReactFoo is a single-day React conference by HasGeek.
We’ll be annoucing the theme shortly
##Format
We are inviting proposals for:
Full-length 40 minute talks.
Crisp 15-minute talks.
Hands-on Workshop sessions, 3 and 6 hour duration.
##Selection process
Proposals will be filtered and shortlisted by an Editorial Panel. Please make sure to add links to videos / slide decks when submitting proposals. This will help us understand your speaking experience and delivery style. Blurbs or blog posts covering the relevance of a particular problem statement and how it is tackled will help the Editorial Panel better judge your proposals. We might contact you to ask if you’d like to repost your content on the official conference blog.
We expect you to submit an outline of your proposed talk – either in the form of a mind map or a text document or draft slides within two weeks of submitting your proposal.
You can check back on this page for the status of your proposal. We will notify you if we either move your proposal to the next round or if we reject it. Selected speakers must participate in one or two rounds of rehearsals before the conference. This is mandatory and helps you to prepare well for the conference.
A speaker is NOT confirmed a slot unless we explicitly mention so in an email or over any other medium of communication.
There is only one speaker per session. Entry to the conference is free for selected speakers. As our budget is limited, we prefer speakers from locations closer home, but will do our best to cover for anyone exceptional. HasGeek provides these limited grants where applicable: two international travel and accommodation grants, three domestic travel and accommodation grants. Grants are limited and made available to speakers delivering full sessions (40 minutes or longer). Speaker travel grants will be given in order of preference to students, women, persons of non-binary genders, and individuals for Asia and Africa first.
##Commitment to open source
HasGeek believes in open source as the binding force of our community. If you are describing a codebase for developers to work with, we’d like for it to be available under a permissive open source licence. If your software is commercially licensed or available under a combination of commercial and restrictive open source licences (such as the various forms of the GPL), please consider picking up a sponsorship. We recognise that there are valid reasons for commercial licensing, but ask that you support us in return for giving you an audience. Your session will be marked on the schedule as a “sponsored session”.
##Important dates:
Deadline for submitting proposals: 23 August 2017
**Conference date: ** 14 September 2017
##Contact
For more information about speaking proposals, tickets and sponsorships, contact info@hasgeek.com or call +91 76763 32020.
Please note, we will not evaluate proposals that do not have a slide deck and a video in them.
VS
VARSHA SAHA
@varshasaha
State maintenance with Redux in a multi layered Javascript Application
Submitted Feb 28, 2017
Technical level:
Intermediate
State maintenance is one of the key challenges we encounter while building a large scale application. If we are building our application as a platform which has some core functionalities to be utilised by ‘n’ clients which also have their own functionalities then state management becomes even nastier.
My talk would focus on key challenges we need to solve for:
- What if the app is huge and acts as a platform, encapsulating child app(s) within it?
- How does the child app(s) operate in isolation as well as interact with main app?
- What if the child apps are on different tech stacks?
The platform that I am developing, is bundled with requirements of building sub-apps on top of it, which also need to scale individually. While the platform provides for core functionalities and widgets that can be utilised by sub-apps, these sub-apps also need to interact with the main app.
If there is a button click on main app which changes/publishes data/view, the sub-app needs to listen, and subsequently conform itself to the change.
This can be made possible by having a common pipeline between the two that records and notifies of each other’s state transition.
This in my case is made possible by Redux as a binding conduit. Redux takes care of state management effectively. When a sub app introduces itself in the container, the two states are combined, and subsequently manifest into a common state tree. The branches of this state tree can then be subscribed by both main and sub-apps.
I, while working at Flipkart’s Customer Experience team have built this platform and on boarded two organisations so far.
My talk would answer to the following premise:
- How is dependency management, state transition and client side routing made possible in this scenario?
- Do we take single store or multiple store approach given that there are multiple organisations?
- How do we use (and reuse) ‘Container & Presentational Components’ to ensure seamless extension and minimal maintenance?
Intended audience:
My talk is meant for all JS developers working on a large scale application. Having basic knowledge of Redux would help but it is not a prerequisite.
Takeaways:
The audience would get a good idea on how to build a scalable application which could be utilised by many clients.
They would learn how to make a clean and readable state tree so that maintenance becomes easier and everything fits together seamlessly.
Outline
0 min - 5 mins:
My introduction and a brief over the topic.
5 mins - 10 mins:
Explain about Redux with a few examples
10 mins - 20 mins:
- Demonstration and walk through of how such an application would work
- Stress on different tech stacks being installed into the main app.
- How the state tree would look like and how the sub apps would utilise it.
20 mins - 25 mins:
Live Coding and on boarding a small app into the system.
25 mins - 30 mins:
Conclude my talk.
Speaker bio
I am a JavaScript developer working for Flipkart Internet Pvt. Ltd. in India. I am passionate about solving large scale problems with simple tech solutions. I just wanted to share this with the larger Front End community after gaining a little bit of experience and a lot of knowledge and exposure in making such a huge application. This architecture is something I have been passionately working on for the past few months and it has turned out to be successful, with minimum work required when new organisations get on boarded. I want my audience to know how a large complex problem, when broken down into a simple structure can change how we look at it and how we develop it.
{{ gettext('Login to leave a comment') }}
{{ gettext('Post a comment…') }}{{ errorMsg }}
{{ gettext('No comments posted yet') }}