#bookbrainz-devel

Leftmost: I looked at one or two of the commits

Nice job on preloading the lists of types - that was something I'd also thought of doing, but hadn't gotten round to

Yeah, mostly what I wanted to check on. Seemed sensible to me, but thought I'd ping you. I'd like to abstract the entity routes a bit more now that the route code itself is largely generic, but I have to think a bit more there.

One potential drawback I had thought of to preloading all that data is that if we want to change any of it, we have to reload the site code

It'd be better if we could somehow refresh it regularly

Oh, they're not cached, though we could cache them. They're just loaded prior to the actual route function being executed.

Ohh I see

Caching is a next step, certainly, but for now it's just route middleware, like the auth stuff.

Ah yeah, I can see now what you're doing with those functions

Still, it's a good change, makes it clearer where things are used and helps reduce duplicated code

(and makes things easier to cache)

True that. :)

Have you tried out the new profile editor?

Not yet. I'll do so this evening.

Ok, that's pretty much how I think our editing forms should behave (for both create and update)

I guess I haven't stated it explicitly and have just been figuring that you had the same plans, but does it make sense to you to have the edit forms just send in a JSON object already filled out that we can give to the appropriate model to deal with?

(As in, field names already matching what the model wants.)

Not sure if that's what you're doing for the profile editor, haven't looked at the branch yet.

Err, I think the field names of the profile editor match the user model

I haven't checked though - it would certainly make sense to have them matching

I'll take a look at the code when I play with it and see.

I have to shop for things to eat this week. I'll probably catch you tomorrow if you're around.

Ok, I'm heading off too, see you then :)

bookbrainz-site/reactify d37ba43 Seán de Búrca: Add missing package requirements

is logging

Users on #bookbrainz-devel: MBChatLogger ruaok kepstin-laptop Freso CatQuest Leo_Verto CallerNo6 Leftmost ocharles_ kurros mb-chat-logger bitmap kuno CatCat johtso

CatQuest, I do indeed like the idea of indexing crazy stuff like that :D

:)

like the Rosetta Stone

:D

ohh one thing.. what about translations.. I mean there are literal ones and then re-imaginated ones. like I have norwegian versions of lots of books

whic is however a bit bigger than a stone tablet :P

type = bolder

:D

granodiorite stele maybe?

and then there are *old* things.. like the Holdbergs "Jeppe på Berged" originally danish, translated to norwegian several times as (written)languages changed

Nordic languages are really fascinating, the way most of them (except finnish) are verly closely related but have evolved differently

and Icelandic being a frozen version of Norwegian

but both these written languages have changed since then

nja.. I'd say færøisk (faroese) is closer to original norse

but today people can even write in their dialects. (for example if I write in my dialect it doesn't really look a lot of bokmål)

even if I live in the capital and I usually *write* bokmål

and then there is "kebabnorsk" immigrant-languages inspired norwegian, not just vokabulary but also grammar

(imagie an english example like written in newspeak)

Heh, the English written language has hardly changed in centuries

also islands uh icelandic isn't quite "frozen", they're just very påpasselig.. uh no english word, with making up new icelandic words for new consepts, rather thanto import words like we do (ie heikopter from helicopter)

careful

oh yea? I've read that shakespear is hard to read?

careful?

påpasselig

sa jeg noe gal

ohh

oh yea

ja takk :D

They're very careful to make up words instead of importing with simple/minor adjustments.

yes

:)

some nynorsk-people try this a bit too. but here it usually gets kinda.. dumb.. kleint? awkward

especially when new words get a norwegianized writing form that clashes with the way regular norwegian is written. we write "sukker" not "sokker" and "kommando" not "kåmmando". so making "smoothie" into smudi" and "crunchy" into "krønsji"" becomes dumb

that's even not how they write it.. I dunno, khrøsnjli or whatever it is

other times it's a bit neat "segway" has become ståhjuling" XD

I've heard the Icelandic word for computer is something along the lines of "calculating witch"

bitmap, new certs sent.

:D

now we only need to wait for the LB to be updated/replaced and we'll have a shiny A+ rating

LordSputnik, I'm wondering about the feasibility of doing the initial form rendering server-side. I feel like this would have a few advantages. It would allow us to have our forms work without JS and we could prefill form fields without having to have a route specifically for Ajax to hit to pull out the content, for two.

Sounds like a good idea to me

Getting rid of another request should also decrease loading time

It also means that we can just keep using the bbid parameter middleware to just load entities whenever a route includes a BBID, instead of having to duplicate that code.

http://www.crmarsh.com/react-ssr/ seems relevant.

The downside of doing this is that we're downgrading templates from Jade to HTML

How do you mean?

Or can the react middleware handle jade templates?

Well, react does generate HTML, which can then be passed into a jade template and rendered there.

Would that happen before they are converted to HTML or after?

I'm not sure I follow the question.

Are you planning to do the react rendering via middleware?

Probably on a route-specific basis, since each edit route has its own form.

My question is, can we continue using Jade for the relevant forms or do we have to convert them to HTML?

We'd write the forms with react, not with HTML or with jade.

Leftmost: I'd rather do all data loading the same for all forms

I'm not proposing that we don't.

I'm proposing that we do it server-side, not client-side.

What's the problem with client side though?

It doesn't have any of the advantages I listed. :-P

It means I can keep doing things with react in the simplest way

What do you mean by the simplest way?

1) Forms working without JS - JS is required for editors, so no advantage there really. 2) Seperate requests is slower, but more responsive for the user, since the site appears to be doing something while it's fetching the data - our editor form pretty much instantly loads now

It means we don't have to include a bunch of new technologies and write more code to get things rendered on the server

Why is JS required for editors, beyond the fact that we're using react for forms? And we wouldn't have to include any more technologies than we already do. We use the same form with maybe an additional handful of lines of code, while we save on having to create ajax-only routes for every form we write and get to keep our simple, consistent entity loading code.

We would still have consistent entitry loading code, it would just not be using the middleware

JS is required for editors because we need it for some aspects of the forms, and because it makes things easier to use

If we're using JS at all, we might as well use it everywhere once users are logged in

"easier to use" and "some aspects" both sounds like reasons it's nice to have, not reasons it's required. We can still take advantage of it for those.

I strongly disagree with that.

We should use JS wherever we can improve user experience but where using it does not consequently degrade user experience when it's disabled.

No, why would an editor disable JS

That makes no sense. Only a tiny proportion of people have JS disabled, and it's not much to ask for people who want to edit to use it

Also, MB requires JS for editing

I think it's a lot to ask when it's unnecessary.

But no-one will be editing the site with javascript off, so why support it?

That's a pretty big assumption.

I think it'd a fair assumption

I don't.

MB has 1000 editors

Less active than that

If you assume 1% of people don't have it on (which is higher than I read recently), then only 10 people would be affected

and that's assuming that 1% of editors have it off - I expect that someone editing an online database is much more likely to have JS on than an average internet user

So far the only real consequence of rendering server-side that's been put forth is that, if there's a brief but noticeable delay in rendering the form, it looks more responsive to render out the page and provide the data. I don't consider this a major concern given the potential benefits, including in code simplicity.

I don't like putting data in the rendered HTML we send from the server

Why?

It seems like it would make it harder to manipulate on the client side

The link I pasted above shows how react can be set up to take control of the data once it's been rendered without much performance degradation.

It's set up to recognize that the component has already been rendered by react and doesn't need to be re-rendered, but can be once it's changed.

Ok, I'll give it a try tomorrow if I have time

I can put together a test tonight as well, if that would be helpful to you.

I'm not sure what else I'd work on anyhow. :-P

Yeah sure, go for it :)

Have you odne all of your goals for this month? :P

Well, I got some better error handling in place and those schema changes in. I can still do the edition format change, but I think those were the only concrete goals I had. :-P

Revision history would be nice - that's on my list but at the end, and it's got at least some node/JS backend stuff :)

and also hooking up the reputation system with that

Good call. I'll see what I can do in the backend for it and maybe poke the frontend with a very long stick.

haha :D

That's about as close as anyone wants me to get. ;)

Leo_Verto might want to help with the front end, if he has time

I've been doing a lot of thinking on the WS and how to consistently represent objects and parameterize populating fields, but it's still kind of a mess in my brain and it's also a project I think would be better undertaken after this release cycle.

I'm aiming to add a new base Resouce class and a new List class (with pagination). I think we could then make new resources/lists just by passing in a schema class and data structure

Yeah, I had been thinking that. I was also thinking about consistently presenting URIs for joined fields (unless they're listed in the populate param) and structuring URIs a bit differently, based on the RESTful API Design document you linked a while back.

I've been thinking we could have a "dumps()" method (like json.dumps" to dump the schema object to a JSON string, and then use a separate function in the WS to detect all the IDs and add URLs

(since the schema doesn't have a clue what a URL is, and probably shouldn't know)

Did I link that?!

I don't remember seeing that before :P

You linked http://restful-api-design.readthedocs.org/en/la...

ahhh yeah, I remember now

I don't think we need "rel", if we're going to add JSON-LD, since that should provide context

(JSON-LD is another thing you could look at, if you have time :D)

kuno is good at that, if you were interested

I just figured it would be good to do something like "foo": { "uri": "/foo/bar" } by default and then "foo": { "uri": "/foo/bar", "name": "Foo-frou", ... } if populated.