** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **
10-15-2018
, 08:56 PM
Quote:
Yes, I feel like you should have solved this problem by now 
There are a few places that are default binary locations, install stuff there and then you don't have to mess with your path. /usr/bin is where package managers usually put stuff, /usr/local/bin is where stuff you "manage yourself" usually gets put. You're probably installing the aws stuff with pip though, right? That should be in your path by default unless you installed python somewhere non-standard.
If there are 10 places you need to keep track of paths you're doing something wrong. I can think of... 2 or maybe 3. If you really have a lot then make a little bash script, like ~/.setpaths, set your paths in there, and source that anywhere that needs to have paths set.
bash is a programming language, not a config system, treat it like one - make programs/scripts/functions/libraries/etc
There are a few places that are default binary locations, install stuff there and then you don't have to mess with your path. /usr/bin is where package managers usually put stuff, /usr/local/bin is where stuff you "manage yourself" usually gets put. You're probably installing the aws stuff with pip though, right? That should be in your path by default unless you installed python somewhere non-standard.
If there are 10 places you need to keep track of paths you're doing something wrong. I can think of... 2 or maybe 3. If you really have a lot then make a little bash script, like ~/.setpaths, set your paths in there, and source that anywhere that needs to have paths set.
bash is a programming language, not a config system, treat it like one - make programs/scripts/functions/libraries/etc
Code:
pip install awscli --upgrade --user
Code:
sudo /usr/local/bin/python2.7 awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws
10-15-2018
, 09:03 PM
Question for all the react people. I'm using BrowserRouter like this:
http://localhost:3000/login works fine when navigating through the app on local and on s3. But if I hit refresh it only works on local where I am running the local webpack dev server. If I do a static build and upload to S3 it static webserver - it returns a 404 when I try to hit /login through deep link or refresh.
Also there is no 302 browser redirect in my network history.
So what's going on here - is the webpack dev server serving routes behind the scenes? Is a production webserver expected to do the same? If so that kinda breaks the idea of a fully static site.
The s3 and cloudfront fixes for this seem to be to redirect all 404 and 403 errors to index.html. This works I guess but it's terrible for SEO.
Edit: ok I guess what's happening is the webpack dev server is just sending anything it can't find to index.html. Unfortunately S3 or Cloudfront doesn't seem to want to do that w/o first showing a 404.
Edit edit: Ok I take that back. If I set the error page on S3 to it's showing the right content but with a status of 404. Because it thinks it's showing the error page. That is just weird and bound to cause problems.
Code:
<BrowserRouter>
<div className="sans-serif">
<Switch>
<Route path="/login" component={Login} />
<Route path="/" component={Main} />
</Switch>
</div>
</BrowserRouter>
Also there is no 302 browser redirect in my network history.
So what's going on here - is the webpack dev server serving routes behind the scenes? Is a production webserver expected to do the same? If so that kinda breaks the idea of a fully static site.
The s3 and cloudfront fixes for this seem to be to redirect all 404 and 403 errors to index.html. This works I guess but it's terrible for SEO.
Edit: ok I guess what's happening is the webpack dev server is just sending anything it can't find to index.html. Unfortunately S3 or Cloudfront doesn't seem to want to do that w/o first showing a 404.
Edit edit: Ok I take that back. If I set the error page on S3 to it's showing the right content but with a status of 404. Because it thinks it's showing the error page. That is just weird and bound to cause problems.
Last edited by suzzer99; 10-15-2018 at 09:14 PM.
10-15-2018
, 09:08 PM
10-16-2018
, 12:30 AM
10-16-2018
, 01:42 AM
10-16-2018
, 03:41 AM
10-16-2018
, 06:13 AM
Quote:
Question for all the react people. I'm using BrowserRouter like this:
http://localhost:3000/login works fine when navigating through the app on local and on s3. But if I hit refresh it only works on local where I am running the local webpack dev server. If I do a static build and upload to S3 it static webserver - it returns a 404 when I try to hit /login through deep link or refresh.
Also there is no 302 browser redirect in my network history.
So what's going on here - is the webpack dev server serving routes behind the scenes? Is a production webserver expected to do the same? If so that kinda breaks the idea of a fully static site.
The s3 and cloudfront fixes for this seem to be to redirect all 404 and 403 errors to index.html. This works I guess but it's terrible for SEO.
Edit: ok I guess what's happening is the webpack dev server is just sending anything it can't find to index.html. Unfortunately S3 or Cloudfront doesn't seem to want to do that w/o first showing a 404.
Edit edit: Ok I take that back. If I set the error page on S3 to it's showing the right content but with a status of 404. Because it thinks it's showing the error page. That is just weird and bound to cause problems.
Code:
<BrowserRouter>
<div className="sans-serif">
<Switch>
<Route path="/login" component={Login} />
<Route path="/" component={Main} />
</Switch>
</div>
</BrowserRouter>
Also there is no 302 browser redirect in my network history.
So what's going on here - is the webpack dev server serving routes behind the scenes? Is a production webserver expected to do the same? If so that kinda breaks the idea of a fully static site.
The s3 and cloudfront fixes for this seem to be to redirect all 404 and 403 errors to index.html. This works I guess but it's terrible for SEO.
Edit: ok I guess what's happening is the webpack dev server is just sending anything it can't find to index.html. Unfortunately S3 or Cloudfront doesn't seem to want to do that w/o first showing a 404.
Edit edit: Ok I take that back. If I set the error page on S3 to it's showing the right content but with a status of 404. Because it thinks it's showing the error page. That is just weird and bound to cause problems.
Here's some example server configs: https://github.com/ReactTraining/rea...ng-your-server
This article has some changes to webpack to get it working locally, then sets S3 error page as index.html and says it works fine https://medium.com/@ervib/how-to-set...s3-d3dffa6ae43 (he's probably at the same spot as you and not bothered by the 404 response if it looks working, I guess?)
Personally I use the react-router <HashRouter> instead of <BrowserRouter> since that seems to work just as well and supports working out of arbitrary folders / subfolders perfectly with no reconfiguration, it seems to me the only cost being a hash in the middle of the visible url. For this ability to dump a HashRouter page in any folder on any server, add:
Code:
"homepage": ".",
Last edited by _dave_; 10-16-2018 at 06:21 AM.
10-16-2018
, 10:49 AM
Quote:
I made a couple passes at async, await, but not in earnest. I want to understand it the "old fashioned" way first. I didn't really want to use multer or anything like it, but apparently fileupload was taken out/deprecated from express and you have to use something third party. I don't quite get the role of 'cb' in there. I don't know if that's just because I don't get it or because it's obscured in multer.
edit: added the last function there
Code:
var storage = multer.diskStorage({
destination: function (req, file, cb) {
cb(null, '../solarreact/public/img')
},
filename: function (req, file, cb) {
fs.readFile('../solarreact/src/ImageData.json', 'utf8', (err, data) => {
if (err) throw err;
imgDataArr = JSON.parse(data);
const filename = imgDataArr[imgDataArr.length-1][2].toString() + '_' + imgDataArr[imgDataArr.length-1][0].toString() + '.jpg';
imgDataArr.push([imgDataArr.length+1, "./img/" + filename, imgDataArr[imgDataArr.length-1][2], "this would be the caption here"]);
console.log(JSON.stringify(imgDataArr));
writeImageData(imgDataArr);
cb(null, filename);
});
}
});
var upload = multer({
storage: storage
});
app.post('/api/imgupload', upload.single('image'), function(req, res, next) {
res.send('this is post route upload');
});
Code:
function writeImageData(jsondata) {
fs.writeFile('../solarreact/src/ImageData.json', JSON.stringify(jsondata), (err) => {
if (err) throw err;
console.log('the file has been written');
});
}
Same goes for writeImageData. You're firing this off as an async process while the primary request/response flow continues on. So any errors won't be handled at all - they just get thrown to the node event loop executor, which has no idea what to do with them. If you want the user to get some input if the file write fails, you'll have to use another callback here and only call cb() inside that. Or use async/await (or straight promises, or the 3rd party async-js lib). You're probably getting an idea what "callback hell" means at this point.
The cb() is basically a nested callback inside filename()/fsReadData(). Whatever function inside multer (obscured but you could look at the code) that executes filename() is feeding a callback (cb()) which it uses to do the actual work. fs.readData takes an anonymous function as a callback ((err, data) => ... ) which gets executed when it's done and that ultimately executes the parent callback (cb) at the end.
Also holy 8-space tabs. Muh horizontal space!
I'll play with this some more when I get into work.
One of the best things about pull requests is multiple users can comment right on the lines of code in question - makes collaboration super easy.
