Thar She Blows!... Part 2
The only other facet that gave me troubles in the React world was trying to work with anything based off the Google Material Design component kits for React. Specifically, troubles getting things working with Webpack or something in Webpack, maybe PostCSS, causing issues with those component libraries. I’m planning on actually doing an entire blog on the issue. It’s not meant as an attack of any kind on any of these projects. I actually love these projects quite a lot which is why I’ve spent so many hours to trying to get them to play nicely together and then nicely still with the eventual project whatever that may be.
When it is all working it’s truly fun and a real step forward in how websites can be made. With ready made, beautifully styled React components being put into place, hot loaded and again cross device, fully web compliant. That being said trying to get those to work did end up taking a significant portion of time that looking back could’ve easily been avoided by simply choosing to use more traditional methods of styling. However since these are the tools I’m choosing to go with for now it was worth doing even though it was and continues to be kinda painful from time to time. The things it can do once working make so many of the front end busy work tasks just an after thought. That’s not an overstatement in my opinion.
In my craze to find the issue with a specific bug I was experiencing I had striped down to basics. At that point I had things pretty much working. Working in as far as making a call to my API based off a user dropdown selection and then displaying those specific results. It had worked beautifully on the desktop with everything I had wanted, react-toolbox components and all. Then I just had to go and check to see how things looked on my iPhone. The only thing that I saw was the toolbar navigation bar at the top and the dropdown selection. No results no matter how many times I tried selecting something. So I had taken the app down to just displaying everything in text and still no improvement.
I ended up on IRC asking some people there if they had any experience with something like that and that’s when someone asked if I was running Browsersync. I wasn’t running Browsersync. Browsersync is an npm package that allows for easier testing across all kinds of devices. In fact if you move your mouse on say a desktop you see the results on your mobile devices as well, all in sync. I thought this would help me solve my issue but after considerable effort to get it working nicely with Webpack, I just ended up with exactly what I had before. No drop down results rendering to my iPhone but clearly working on my laptop but this time they were synchronized so I guess that’s something.
My last resort was Stack Overflow. I had been getting some errors in my Python console whenever the API was triggered on the server so I suspected my problem may be there. This led to more time messing with my CORS settings which was a red herring but did produce in the end a cleaner setup and so wasn’t a complete waste of time but more than I’d like to spend on something so basic. After a couple of days I had my errors resolved with the help of a very kind “D.Shawley” on Stack Overflow.
Yet the bug remained. This left me with no errors in any form of browser be it desktop or mobile and no errors being output by my Python console. A true bug indeed then. Congrats are in order I guess. The only other big pitfall was trying to use Superagent as my ajax API helper. It was another area where no matter which way I attacked it, things just never worked properly or I’d have some kind of errors. Simply deciding to give Axios a try solved my issues and had I done that earlier would’ve cut time down considerably again.
Since then I’ve considered whether I was overfetching data from my API and that’s what was causing my problems. So if GraphQL would be a simple thing to switch to I may look at that. More likely though I’ll just end up scrapping that project and learning from the experience. Really, I don’t think I was overfetching either. If anything it could’ve been due to the poor organization of my API in general.
Most likely I’ll try redoing the app with another Python framework, maybe something like Sanic or even Flask would be totally fine now in retrospect. Because in all honesty this app didn’t need to be this advanced. I shot for the moon because I wanted it to be a learning experience as much as I’d hoped for it to be something cool I could show prospective clients or take into a job interview. I didn’t make it or not in the way I’d wanted and that’s fine. I could just keep on making it and just say it’s for desktop only and no mobile. That’s entirely possible and would be fine. I had just envisioned it working on mobile as well since that’s primarily how people like to be updated on things I figure. So I may just decide to do that though my rendering issue may rear it’s ugly head again as the project progresses on desktop as well. It may not but it’s a possibility.
In the end I learned a lot. I learned a lot about some of the differences in Python frameworks not only in how they work but the communities around them. I will note that the #Tornadoweb IRC channel on Freenode is constantly silent though it has about 15-20 people in it at any one time. I’ve literally never seen anyone say anything. Which reinforces my theory that the framework is dead or in it’s last days before dying. The #Pocoo channel(Python Flask) by comparison is busy with people talking all the time and asking & answering questions all the time. Similarly with the heavily populated #ReactJS and #Javascript channels.
They aren’t love fests to be sure but they DO give their feedback and there’s always one or two individuals actively helping people. Now I’m not saying that people are required to act as helpdesk programmers. Far from it. But if you’re in an IRC channel and someone asks a question you know the answer to or have some experience with then why not help them out or give your input? Otherwise why are you in a chat channel in the first place? But I digress, again. I learned a lot about restful API’s and the Javascript helpers out there and some of the differences between them and some of the methods like promises or callbacks. I learned a hell of a lot about asynchronous activities both in Python and Javascript but definitely the former. I got to use the Python Scrapy framework which I know I’ll be using again.
Had I to do over again though I’d definitely not have used Tornado. It’s amazing at what it can do but was just plain overkill for what my app needed. I would’ve definitely given up earlier on using react-toolbox or anything with the Google Material Design component libraries. I should’ve been much more willing to try Axios after so much trouble with Superagent. In the future I’ll just try all the commonly used methods if it doesn’t take too much trouble and something like an ajax API helper library although they can do a lot just really don’t take that much to setup and get going.
One thing I will say I wouldn’t change although it does add needless complexity is the use of React. Could I use something else that would be far easier? Sure. As I’ve said before though, or if not I’m saying it here. If I’m going to be doing work on the front end then working with React is what I want to be doing it with. I’m fully aware that makes my start a lot more difficult. The perfect example being this project. And while I certainly won’t turn away business from people and businesses that just want a website. That’s not the work in web development that I really think I want to be doing.
What I want is to be making web apps or websites that are functional and helpful. That haven’t neccessarily been created yet. That’s what peeks my interest. Another being working with the massive amounts of data we have these days. Whether smart devices or just data you can scrape off the web what you can do with that data is utterly scary sometimes. Seeing that progress got me interested in programming in general again which is why I got into Python. Working with data in Python is fairly straightforward and pleasant. I really feel that React and it’s virtual DOM can do a lot in terms of showing that data. I can imagine stock apps using this combination quite well to show things as fast as possbile. So out of all my bad choices this is the one I’ll stand by because of the simple reason I’ve chosen React as my niche on the front end.
Like I said I may continue the project or I may never work on it again but it was time well spent all in all. I probably could’ve learned a lot more had I just pumped out ten different apps other people had already made before but maybe I wouldn’t either. The one thing I can say for sure was I learned a lot about what goes on in the real world of making choices to create an actual thing. Because although I had made some wrong decisions I took a good amount of time researching each aspect before hand. I didn’t just wake up and suddenly using Tornado popped into my head. I did it because my last project ran a bit slowly but in hindsight it was probably definitely due to the use of Beautiful Soup and not because of Flask itself. So I had a good reason it was just misguided. Now I know better.
I also know now which I knew then as well is that you simply cannot think of all the variables that you’ll face on a project. You do your best to plan and research but at a certain point you just have to get going and deal with the problems as they come up. That’s something I know I’ll face on every project so no sense in delaying getting started for too long. Just a willingness to try other approaches without thinking that I’m failing is something I’ve learned as well. If I’m getting errors with something I’m using and everyone else seems to be using it just fine it’s okay. It may not be me or the project and just trying something else can resolve the issue and the project can progress.
Brandon