So currently, I am exploring the world of AngularJS and have encountered a problem.
I am building a very primitive blog application supported by Firebase, and I want to use Angular validation to check whether a slug is already in use. However, something is going wrong here. This is the directive that I wrote to check whether a slug is already in use (without Firebase):
http://jsfiddle.net/Lk6fY/1/
As you can see, this works like a charm. Now, I can insert the Firebase call here, instead of the primitive check, but this forms two problems:
On every keyup, a request would be send to Firebase. If this is an application for one user, this would not really be a problem, but imagine 5000 people at the same time trying to post a blog entry (which of course wouldn't happen, but I want to learn the right approach).
Nevertheless, I did try it, and it didn't really work as expected. I think it has to do with the response time to the Firebase servers, because:
foo-bar would be valid, until the user pressed the submit button, whereas foo-ba would be invalid, but after pressing the submit button the user could simply continue.
So therefore my question: how can this be solved in an efficient an appropriate manner?
Ideally, I would like the directive to connect to Firebase after either the title or slug fields are not anymore in focus. How would this be possible?
Related
After making a post request to add a blog, i then want to display those blogs on the same screen.
So there is no refresh.
What is the best way to get that updated list of blogs. Do i:
make another GET request to get the list of blogs and show a loading bar
just show the posted blog and assume the async POST will be successful
or is there a better way to tackle this?
Thanks
The best tactic really depends on the user experience and your opinion of what the new blog being on the screen might suggest to the user.
For some products, having the page move on immediately, and assuming the back-end is keeping up (eg for dragging a card to another column on a scrum board), will be the most pleasant for the user - no lag, and if the update it didn't go through and the card jumps back, no big issue.
For posting a blog though, a user might expect that if they can see their blog on the website, that that is confirmation of it going through the backend successfully. For that reason I think that another GET request is the better option, as it implicitly confirms to the user a successful POST.
It depends on the rest of your app and what you value.
The first one makes sense if you are using that same back-end controller in another part of your app that shows the blogs (maybe even before the blog is added) and you want to reuse it there.
The second one makes sense if you want to be network efficient and don't mind writing different back-end controllers for different back-end interactions. Also, you don't need to asume it will be successful, you need to catch errors and handle them.
An approach could be to do an empty post that returns the blogs but if the post has a new blog, then it is added and also returns all other blogs.
I am scraping a website that uses React for the front-end. So far it seems that I have to use their search form in order to arrive at the results page.
The problem is that the site clears out the search form's selected options from a dropdown (its state) every time the page is refreshed and therefore it makes scraping significantly slower. I know that it's working as intended, but if there was a way I could directly manipulate the state then it could speed up my scraper as opposed to re-selecting all the choices from the little buttons.
I don't think it uses any type of persistent storage or local storage at all, for every selection, otherwise the form probably wouldn't be cleared on refresh.
I can see that the years options for the form are always present in a data-attribute (data-years=["2017", "2016", ...]) but only for the years. And when a year (or any option from the dropdowns) is selected, a hidden field is populated with a value such as <input type="hidden" name="year" value="2017">.
Is this all that React uses for temporary storage (aka. state)—hidden fields?
And for the second part of my question, what type of event is fired off when there is a state change? How could I trigger it manually? When I select a year, for example, I want the form to give me the options for the next dropdown—given the year.
React does not use the DOM at all to maintain state. The example you provided is simply a poorly written React app. Normally everything will kept in memory (closured code so nothing in window/global) and React will update the DOM as she wants. :)
This means I don't think you'll be able to read/detect React instrinsic state changes from the outside. Interactive scraping should work like a user using the page, without any hint of what tech it's really using.
Depending on the technology you're using for scraping, you could indeed simulate or generate the real DOM events. When we need to write some end to end tests for a React app using the ubiquitous Selenium server, we normally have to manually click on buttons, options and so on and allow time for the React app to react accordingly and do its magic (like fetching more data and updating the page) and afterwards read document contents to verify everything was working. It's basically "scraping" with a desired output to verify, your test assertions.
If you're scraping static pages only (curl style: fetch the HTML and work your way with the original HTML response), I don't think you'll be able to handle a Javascript form. You need your scraper to be interactive.
Something like PhantomJS apart from the mentioned Selenium/WebDriver may help.
I have a small admin page setup with ng-admin. Creating elements works without any issues.
What I want to achieve though is that I sent the user to a different page where he can perform some action that will alter the created item(scraping some data elsewhere for the element and asking if its correct).
Is there a way to overwrite the custom route that is on the submit button in ng-admin to sent the user to a custom page, also inside of ng-admin?
I would like to not tinker with the ng-admin code to not break the functionality on other elements pages.
Tere is no built-in way to do that in ng-admin 0.9. But a recent addition to the 1.0.0-dev branch (view.prepare()) might help you, see https://github.com/marmelab/ng-admin/pull/756.
I have a simple app built with AngularJS routes which is loading the controller and template for each path. I have a register form and login form on separates paths/templates. Say I go to the login form (/#/login) and enter my username/password, if I then hit "Register" (redirects me to /#/register), and then I hit back in my browser, it will return me to /#/login but the form will now be empty; the information I typed in has been removed.
Expected behaviour would be that the form data is still there.
Anyway to make that happen (without manually caching the data in a service)?
I'm guessing when the page changes, Angular is tossing the old template data and reloading the template again. Is there a way to instead cache that page template/DOM and reload it when the user returns to that path (instead of downloading and showing new template file)?
Well, this is a bit tricky. The browser should implement this kind of feature out of the box. Firefox started doing some work around this "issue" but I don't really know the current status of it.
Alternatively you can use a bit of javascript with LocalStorage to make this works. You're using AngularJS you can create a Directive that encapsulates this feature to be used on multiple places.
Basically you need to create a mechanism that translate an field to and unique-identifier and a value. Every time the user type on the field, you update the store. If the user "finish" the interaction on the form, you clean the value from the store.
You can also grab a jQuery plugin and just create a directive that uses the plugin.
https://github.com/kugaevsky/jquery-phoenix (never tested it).
TL:DR
There's nothing you can't do using a DOM property/attribute or something similar.
You'll need to get your hands dirty on some javascript to make this happen.
I am thinking to build my own like system, as a way of learning various technologies including Javascript; and to gain a better understanding of authentication and XSS.
Use-case:
Unique ID generated atop a little bit of Javascript code, for embedding in any website
When unique user presses this like button, a +1 is triggered to the 'score' of that UID
On unique user's profile, display what they like'd
I'm unsure as where to start... how would I go about building this system?
Building such system is easy. Securing it properly, making it flow nice and be easy to integrate is the hardest part. You should ignore the latter 3 for now. I would start with a JS file that searches the DOM for any elements with the ID of "mylike" (for example) which inserts a button on to said page. Once a user clicks the button it simply does an AJAX post back to your server containing information like the page title and page URL. I think it may be best for your backend to generate the ID, maybe an algorithm based on the title + URL.
To include user data to know what user liked what I'd suggest a persistent cookie that has a session variable to link to a user in your back end. Simply pull the cookie out using JavaScript and send the cookie along with the AJAX request.